Re: RFC: THE OFFLINE SCHEDULER

[Thomas Gleixner]

On Fri, 28 Aug 2009, raz ben yehuda wrote:
> On Thu, 2009-08-27 at 10:51 -0600, Chris Friesen wrote:
> > On 08/26/2009 03:37 PM, raz ben yehuda wrote:
> > > 
> > > On Wed, 2009-08-26 at 15:15 -0600, Chris Friesen wrote:
> > 
> > >> We gave it as close to a whole cpu as we could using cpu and irq
> > >> affinity and we used message queues in shared memory to allow another
> > >> cpu to handle I/O.  In our case we still had kernel threads running on
> > >> the app cpu, but if we'd had a straightforward way to avoid them we
> > >> would have used it.
> > 
> > > Chris. I offer myself to help anyone wishes to apply OFFSCHED.
> > 
> > I just went and read the docs.  One of the things I noticed is that it
> > says that the offlined cpu cannot run userspace tasks.  For our
> > situation that's a showstopper, unfortunately.
>
> Given that your entire software is T size , and T' is the amount of real
> time size, what is the relation T'/T ?
> If T'/T << 1 then dissect it, and put the T' in OFFSCHED. 
> My software T's is about 100MB while the real time section is about 60K.

Chris was stating that your offlined cpu cannot run userspace
tasks. How is your answer connected to Chris' statement ? Please stop
useless marketing. LKML is about technical problems not advertisement.

> They communicate through a simple ioctls.  

This is totally irrelevant and we all know how communication channels
between Linux and whatever hackery (RT-Linux, RTAI, ... OFFLINE)
works.

>               CPU isolation example: a transmission engine.
> 
> In the image bellow, I am presenting 4 streaming engines, over 4 Intels
> 82598EB 10Gbps. A streaming engine is actually a Xeon E5420 2.5GHz.
> Each engine has ***full control*** over its own interface. So you can:
> 
> 1. fully control the processor's usage.

By disabling the OS control over the CPU resource. How innovative.

> 2. know **exactly*** how much each single packet transmission costs. for
> example, in this case in processor 3 a single packet average
> transmission is 1974tscs, which is ~700ns.
> 
> 3. know how many packets fails to transmit right **on time** ( the Lates
> counter) . and on time in this case means within the 122us jitter. 

Are those statistics a crucial property of your OFFLINE thing ?
 
> 4. There are 8 cores in this machine. The rest 4 OS cores are ~95% idle.
> The only resource these cores share is the bus. 

That does not change the problem that you cannot run ordinary user
space tasks on your offlined CPUs and you are simply hacking round the
real problem which I outlined in my previous mail.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/