Linux-kernel mailing list archive 2000-26,: Re: owner field in `struct fs'

# Re: owner field in `struct fs'

Alexander Viro (viro@math.psu.edu)
Sat, 24 Jun 2000 20:25:57 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Richard Gooch: "Re: owner field in `struct fs'"
- Previous message: Chris Wedgwood: "Re: [PATCH] Compile fixes for 2.4.0-test2"
- In reply to: Richard Gooch: "Re: owner field in `struct fs'"

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/

- Next message: Richard Gooch: "Re: owner field in `struct fs'"
- Previous message: Chris Wedgwood: "Re: [PATCH] Compile fixes for 2.4.0-test2"
- In reply to: Richard Gooch: "Re: owner field in `struct fs'"