On Thu, Jun 14, 2012 at 03:48:12AM +0200, Ariane van der Steldt wrote:
> Hi,
>
> This diff implements yielding in the vm system, with the intention to
> make expensive system calls preempt every once in a while, to allow
> userland system calls to progress.
>
> It's a very conservative application at the moment, only interleaving
> during memory unmapping. If this works, we can start adding the
> mechanic to other expensive system calls not just in uvm, but anywhere
> the kernel is kept locked for long stretches of time.
>
FWIW, few years ago I did a lot of tests and munmap() was by far
the longest kernel code path. IIRC the second was ffs w/ softdeps.
> Technically the diff is incomplete, since it does not consider the very
> big problem of the biglock. And that's because the biglock lacks a
> __mp_lock_is_contended() call: if we hold the biglock and another cpu
> wants the biglock, ideally it will inform us so we can sidestep and
> temporarily grant access.
I've read the diff, but I still don't understand this part. Why
wouldn't the naive approch work for MP as well? I mean, on UP
systems we do:
for (;;) {
one_cycle_of_heavy_stuff();
preemp();
}
and preemp() would check for a flag set in the clock interrupt and
possibly call mi_switch() to run another process. On MP systems,
mi_switch() would release the kernel lock, wouldn't it? If so,
other processes can invoke syscalls. In this case I don't see the
difference between MP and UP.
-- Alexandre
