Re: [PATCH] scheduler patch, faster still

yodaiken@chelm.cs.nmt.edu
Sat, 3 Oct 1998 16:44:45 -0600 (MDT)


>
> > One easy project is to support memory managed RTLinux tasks. This
> > was the original design and we dropped it for performance reasons and
> > when modules started working well. But it should be relatively easy to
> > take a 4Meg chunk of memory, reserve it for RTLinux modules, make
> > a map for it, and then fix the rtscheduler to really switch.
>
> Providing you dont require atomicity of memory allocations is there any
> reason it shouldnt queue the kernel a request by kmalloc now and then and
> keep a local pool ?

We already use a mechanism to atomically queue kernel requests
via a second BH queue and those routines could kmalloc. I'm generally against
dynamic resource allocation on the RT side: it is RT, it can't wait for
resources, if not, it can run under Linux. Most RT kernels are filled with
bad implementations of the mechanisms of a non-rt kernel.
I'd much prefer to have the Linux side do all the complex stuff.

The other issue is how mm will work. My initial theory is that one could
allocate a chunk for the RT system (in linux kernel mode)
and put all RT tasks in it rather than alloc a map and space for each RT task.

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