Re: [ANNOUNCE] Adeos nanokernel for Linux kernel

[Daniel Phillips]

On Wednesday 05 June 2002 23:22, Oliver Xymoron wrote:
> On Wed, 5 Jun 2002, Daniel Phillips wrote:
> 
> > > And that alternative sucks. Think scalability.
> > >
> > > >   2) Implement a filesystem with realtime response
> > >
> > > And your shared fs alternative sucks. Think abysmal disk throughput for
> > > the rest of the system. Think starvation. Think all the reasons we've been
> > > trying to clean up the elevator code times ten. And that's just for the
> > > device queue, never mind the deadlock avoidance problems. See "priority
> > > inversion".
> >
> > What kind of argument is that?  It sounds like: because our current block
> > interface sucks, all block interfaces suck, and always will.  On the
> > contrary, I believe our current interface sucks precisely because it is
> > not built according to sound principles of realtime design.
> 
> No, the above is a theoretical argument about how optimizing disk access
> and locking works that's in no way specific to Linux. Remember, hard RT is
> trades throughput for latency guarantees.

This is a mantra I keep hearing repeated, and it is a myth.  The correct
version goes more like: "in a realtime system, meeting deadlines is more
important than efficiency".  That doesn't mean you can't have both, and
please see my earlier description of the realtime system c/w gui, running
on a 486.  Oh wait, it also ran on a 386.  16 Mhz.

> Worst case for this is devices
> queues for disks. Go through the thought experiment of what happens when
> an RT task and a !RT task interleave disk access. Worse, what happens when
> they're creating files (and all the locking that entails) in the same
> directory.

I mentioned somewhere that the realtime filesystem would get its own
volume.  That's a big help, because it means that the entire filesystem
can run in the RTOS, and we only have to worry about the block queue,
which is an interesting and tractable problem from the realtime point
of view.  Obviously, we want the RTOS to operate the block queue, and
yes, we want it to be efficient.

Our current block queue design would benefit a lot from the kind of
thinking that would be required to make it realtime.

-- 
Daniel