> Date: Thu, 14 Jun 2012 08:58:25 +0200
> From: Alexandre Ratchov <a...@caoua.org>
>
> 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.
Indeed. Except that we probably should yield() instead of preempt()
since this is a voluntary context switch. At least that is what the
pool subsystem does.
The hard bit is to determine how much work to do in one cycle. Should
be enough work to still spend a significant fraction of a timeslice
otherwise unmapping stuff becomes too slow.
