AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090114120349.527f0564@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<jobi.ariyamannil@onstor.com>,<dl-designreview@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#mh/Mailbox/design review	0	2779531E7C760D4491C96305019FEEB51763B781CF@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Wed, 14 Jan 2009 12:04:06 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Jobi Ariyamannil <jobi.ariyamannil@onstor.com>
Cc: dl-Design Review <dl-designreview@onstor.com>
Subject: Re: TuxRx Functional Spec
Message-ID: <20090114120406.46457b5e@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB51763B781CF@exch1.onstor.net>
References: <20090113201411.4080c3aa@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51763B781CF@exch1.onstor.net>
Organization: Onstor
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

These are some good questions.  Answers inline; I will incorporate some
of this into the doc.

On Wed, 14 Jan 2009 11:32:35 -0800 Jobi Ariyamannil
<jobi.ariyamannil@onstor.com> wrote:

> 1.    Have you compared the benefits of user processes versus kernel
> threads/drivers for the EEE applications?  Why user space application
> model is chosen?

We will be using a kernel thread for the ACPU.  There will likely be
one or more user space daemons that haven't existed before, but
those daemons could be moved to kernel space if that proves to be
necessary.  I'm predicting it won't: they will be in the areas of
configuration and similar; not on the performance path.

> 2.    I guess threads in Linux can be preempted for high priority
> tasks or interrupts. A lot of EEE code is not expecting such a case.
> How this will be handled?

The ACPU thread will not be preempted because it will be the only thread
[group] runnable on that core.

> 3.    Current TXRX code is using state machines and no threads are
> used.  Will the new model continue using state machines? Will the
> state machines be efficient with the context switches in a typical OS
> environment?

The ACPU code will be as untouched as possible and is not expected to
suffer context switches since it will have a CPU core to itself.  See
the pretty picture that took me hours to draw.

> 4.    Does the Linux on TXRX use swapping? What will be the swap
> device?

Paging yes, swapping no.  No swap device.

> 5.    Do the SSC and TXRX/LINUX cores share the same compact flash?
> How do they serialize?

The current plan is to use some space on the CF through the SSC, NFS
mounted. There will be a IP bridge between the TuxRx and the SSC using
the management bus driver.  The space will be used for logging and other
such needs, not for root file system, except for development
environments, which most often will have NFS root filesystem either on
some external server (like we can do now with the SSC) or on the CF.

> -----Original Message-----
> From: Andy Sharp
> Sent: Tuesday, January 13, 2009 8:14 PM
> To: Jonathan Goldick
> Cc: dl-Design Review
> Subject: Re: TuxRx Functional Spec
> 
> 
> 
> New versions available here:
> 
> 
> 
> http://intranet.onstor.net/md/Software/Kegg/Functional%20Specs/tuxrx_func_spec.pdf
> 
> 
> 
> http://intranet.onstor.net/md/Software/Kegg/Functional%20Specs/tuxrx_func_spec.doc
> 
> 
> 
> Comments not covered in the changes replied to inline
> 
> (section 5. c,d,f):
> 
> 
> 
> 
> 
> 
> 
> On Wed, 7 Jan 2009 11:47:32 -0800 Jonathan Goldick
> 
> <jonathan.goldick@onstor.com> wrote:
> 
> 
> 
> > 1. Section 5:
> 
> >   a. How will memory change for the ACPU?  Will we have just as much
> 
> > available for NFS/CIFS as before?  Will we get more memory back
> 
> > because of increased efficiencies or lose some due to new overheads?
> 
> 
> 
> > b. Will core dumps work the same way since now there will also be
> 
> > user-space processes that didn't exist in EEE that could also crash?
> 
> > Will they still go to the management volume and have the same names
> 
> > as before?  Analyzing a Linux core will have a new procedure.
> 
> 
> 
> > c. Will the system boot faster/slower/same?
> 
> 
> 
> I would say about the same.  It seems to me that the cumulative time
> 
> for TXRX image to load and for it to become "ready" is about 20
> seconds
> 
> (for production build) and I expect it to be about that for TuxRx.
> 
> 
> 
> > d. Will we still need to use wd_kick for watchdog support in the
> > ACPU
> 
> > or is Linux handling that in a new way?
> 
> 
> 
> Really an implementation detail that hasn't been decided yet.
> 
> Probably will be based on what gives the best functionality.
> 
> 
> 
> > e. Does the ACPU performance profile change now that you are
> > probably
> 
> > using the default Linux scheduler instead of our current model of
> 
> > polling routines with a maximum number of work items before
> > returning
> 
> > to the main loop.  This question edges on design but has an external
> 
> > manifestation of performance.
> 
> 
> 
> > f. In general, this section has too little detail about what
> 
> > workflows will change, especially around diagnostics and support.
> 
> 
> 
> Agreed.  I will try to be watchful to update the document as they
> occur
> 
> to me.
> 
> 
> 
> > 2. Section 6
> 
> > a. I suspect that the UI for rcon and the associated console
> > commands
> 
> > will likely change. This will in turn impact diagnostic procedures
> > we
> 
> > use in the field. For example, the 'eee' command is how we look at
> 
> > memory utilization and that will be completely different in Linux.
> 
> > You should say something about these commands, especially ones like
> 
> > 'req trace on' which is the debug ACPU command that traces the
> 
> > CIFS/NFS states.
> 
> > b. Do we have to login to yet another root account, this time for
> > the
> 
> > TXRX?
> 
> >
> 
> > 3. Section 10, you can probably get a better estimate by how much
> 
> > head room is available on the ACPU and FP processors today at
> > maximum
> 
> > spec load.  Since your changes will not be increasing their
> 
> > performance in the first incarnation, which is a pretty good
> 
> > estimator assuming that you are not also changing the useable memory
> 
> > and scheduler for the ACPU.
> 
> >
> 
> >
> 
> > -----Original Message-----
> 
> > From: Andy Sharp
> 
> > Sent: Tuesday, January 06, 2009 3:27 PM
> 
> > To: dl-Design Review
> 
> > Subject: RFC: TuxRx Functional Spec
> 
> >
> 
> > Please review and comment on the TuxRx Project Functional Spec:
> 
> >
> 
> > http://ripper.onstor.net/eng/tuxrx/tuxrx_func_spec.pdf
> 
> >
> 
> > http://ripper.onstor.net/eng/tuxrx/tuxrx_func_spec.pages
> 
> >
> 
> > Thanks,
> 
> >
> 
> > a
