In article <200004200148.KAA04953@asami.proc.flab.fujitsu.co.jp>,
<kumon@flab.fujitsu.co.jp> wrote:
>Andi Kleen writes:
> >
> > schedule() does not require the kernel lock
>
>Unfortunately, schedule() does.
Well, not really.
What schedule() does is to just re-instate a previously held lock (yes,
you obviously know that, I'm just stating it clearly). Which means that
it's not really schedule() itself that needs the lock, and that you
should not look at schedule() as the "offender".
The real offender, of course, is the caller of schedule(). So the "cost"
is reall yjust attributed to the wrong function.
It might be interesting to re-write "schedule()" as a macro or inline
functions, something like
static inline void schedule(void)
{
__schedule();
reacquire_kernel_lock(current);
}
and see which callers are the worst hit, and try to fix them up.
It's almost certainly going to be "poll()" that is the big one
contributing to schedule(), judging by your other numbers.
In fact, poll() look sto be badly written wrt the big kernel lock.
Notice how sys_poll() does something like this:
lock_kernel();
fdcount = do_poll(nfds, nchunks, nleft, fds, wait, timeout);
unlock_kernel();
and all of do_poll() (including the schedule() call in there) is running
with the kernel lock held. What you might try to do is to remove that
[un]lock_kernel() pair, and instead put it inside do_poll() like this:
set_current_state(TASK_INTERRUPTIBLE);
+ lock_kernel();
for (i=0; i < nchunks; i++)
do_pollfd(POLLFD_PER_PAGE, fds[i], &wait, &count);
if (nleft)
do_pollfd(nleft, fds[nchunks], &wait, &count);
+ unlock_kernel();
wait = NULL;
instead. Which looks costly because of the for()-loop, but that loop
really shouldn't normally be run more than twice for every invocation
anyway. And moving the kernel lock inwards will make it easier to
eventually remove it altogether from this path..
Linus
-
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 : Sun Apr 23 2000 - 21:00:17 EST