On 29 Jan 2002, Robert Love wrote:
> On Tue, 2002-01-29 at 20:26, Andrew Morton wrote:
> > Just a little word of caution here. Remember the
> > apache-flock-synchronisation fiasco, where removal
> > of the BKL halved Apache throughput on 8-way x86.
> >
> > This was because the BKL removal turned serialisation
> > on a quick codepath from a spinlock into a schedule().
Yes, but the other factor to consider here is why did the extra schedule
take place at all? I think this is a actually a scheduler issue, and
I'm hoping that the new scheduler will behave better in this case. A
call to schedule() should not happen unless the woken process has a
higher priority than the process that did the unlock, but the old
scheduler evidently always calculated this to be the case. But we
really want the process that did the unlock to continue running (until
the end of its timeslice, if not preempted or blocked before then), just
as it would when the lock was a spinlock. It would be interesting to
see whether the new scheduler gets this right.
Am I remembering the problem correctly?
Nigel Gamble nigel@nrg.org
Mountain View, CA, USA. http://www.nrg.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:12 EST