On Sat, 24 Jun 2000, Richard Gooch wrote:
> Alan Cox writes:
> > > Should be. If you set SCHED_FIFO and give a process the highest
> > > priority, then you are guaranteed that once that process gets the CPU,
> > > it will not be switched out until it relinquishes it (block on I/O,
> > > sleep or exit).
> > >
> > > Just make sure you mlockall current and future pages, and do a dry-run
> > > of the RT functions.
> >
> > Doesn't help you. If your stack bumps up another page or you hit any
> > other resource requirement we dont guarantee your rt task wont stall
>
> So touch some extra stack pages before sending the "I'm up and
> running" signal. And use setrlimit(2) to ensure there isn't a CPU time
> limit or something.
Erm... And you are _still_ claiming that it's less brittle? It's way more
complex, it relies on a lot of mechanisms and it _does_ bloat the kernel.
Yes, I mean that - for every module you are getting rid of one word in
.data and get back MOD_INC_USE_COUNT + at least one MOD_DEC_USE_COUNT
in the .text. And for quite a few modules you are getting a couple of
non-inlined functions sitting in the .text. Care to count bytes from the
int foo_open(<whatever>)
{
atomic_inc(&__this_module.uc.usecount);
__this_module.flags |= MOD_VISITED|MOD_USED_ONCE;
return 0;
}
int foo_release(<whatever>)
{
atomic_dec(&__this_module.uc.usecount);
__this_module.flags |= MOD_VISITED;
return 0;
}
and tell what kind of architecture manages to fit both into one word?
Even if there is some code in ->open() and ->release() (frequently there's
none) you still have the atomic_... and |= business. And if ->open() may
fail you have at least one more MOD_DEC_USE_COUNT.
If you hope that we can avoid touching these suckers - forget it. We have
to go through them anyway, since quite a few did MOD_INC_USE_COUNT _after_
the blocking kmalloc() and its likes.
-
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/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:05 EST