AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Bill.Fisher@lsi.com>,<Maxim.Kozlovsky@lsi.com>,<Andy.Sharp@lsi.com>,<Rendell.Fong@lsi.com>,<Brian.Stark@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	4B189D20.3000900@lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 4 Dec 2009 09:51:52 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Fisher, Bill" <Bill.Fisher@lsi.com>
Cc: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>, "Sharp, Andy"
 <Andy.Sharp@lsi.com>, "Fong, Rendell" <Rendell.Fong@lsi.com>, "Stark,
 Brian" <Brian.Stark@lsi.com>
Subject: Re: ACPU and NCPU Threads Processing Algorithm
Message-ID: <20091204095152.2d440f49@ripper.onstor.net>
In-Reply-To: <4B189D20.3000900@lsi.com>
References: <4B189D20.3000900@lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 3 Dec 2009 22:24:48 -0700 William Fisher <bill.fisher@lsi.com>
wrote:

> Guys:
> 
> I have created/reworked the ACPU and NCPU kernel thread
> code for the TXRX CIFS/NFS/NETBIOS and the NCPU TPL
> support functions.
> 
> The old ACPU code was bound to
> a core and also polled the RCON driver for data
> received via interrupts from the SSC. Hence it
> was basically a processor and memory warmup test loop!
> 
> I have also reworked the RCON code on the TXRX side
> to not call the eee_poll() procedure, so that the
> old scheme is now longer the inverted approach.
> 
> My question is the following;
> 
> I was thinking about reworking the enqueue procedures for the
> various local_Queue's and IPC queue's so that
> a wakeup would be generated when things were enqueued.
> This would allow the ACPU/NCPU threads to do the
> normal wait_XXX() Linux kernel operations until
> an appropriate event happened.
> 
> After looking at the code again in more detail today,
> I am thinking that this isn't necessary and might
> introduce more overhead that it's worth.
> 
> Instead I'm leaning toward simply having each
> thread periodically sleep if there is not work to be done.
> The sleep period could be adjustable, but initally say
> we use 1 second. Upon wakeup, we do some checking
> and if nothing needs to be done go back to sleep again.

OK, but should be more like 10us or something.  At most 1ms.  We can
play with it as necessary to tune it after we see how it performs.

> Does anyone seriously object to this approach?
> 
> Max and I talked about this awhile ago, and this
> was what he suggested initially. I hadn't decided
> until now, that adding more overhead to the
> basic IPC mechanism might be more than is saved.
> 
> The reworked ACPU thread on the TXRX, now interrogates
> the RCON driver to determine if characters have arrived
> from the SSC. If so it calls the rcon_shell_prompt() procedure
> to decode and execute the requested shell command.
> Otherwise is simply moves on to call the
> eee_poll() function to process requests.
> 
> The NCPU thread supporting the TPL callback's
> and some of the FP TPL support, will not be all
> that heavily used except for the FP transmit
> operations. Hence I am thinking about
> adding the wakeup's in this case, since there
> is a pretty limited number of cases that
> need to be processed.

This sounds good to me.  Possibly gives us some other flexibility we
may like in the future.

> Anyone have some thoughts on some different approach(es)?
> 
> Later,
> 
> -- Bill
