Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning

From: Ulrich Drepper
Date: Tue Apr 06 2010 - 13:34:49 EST


On Tue, Apr 6, 2010 at 09:44, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
> That gives you something along the lines of
>
> Â Â Â Ârunaddr = find_run_flag(lock);
> Â Â Â Âdo {
> Â Â Â Â Â Â Â Âwhile(*runaddr == RUNNING) {
> Â Â Â Â Â Â Â Â Â Â Â Âif (trylock(lock))
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Âreturn WHOOPEE;
> Â Â Â Â Â Â Â Â Â Â Â Âcpu relax
> Â Â Â Â Â Â Â Â}
> Â Â Â Â Â Â Â Âyield (_on(thread));
> Â Â Â Â} while(*runaddr != DEAD);

There still has to be an upper limit in the number of rounds of the
wait loop )some locks are held for a long time) since otherwise CPUs
are unnecessarily long tied up. And the DEAD case is only for robust
mutex handling. But in theory I agree.

We already have the set_tid_address syscall. This could be
generalized with a new syscall which can provide the kernel with more
than one pointer to store "stuff" in: TIDs, scheduling info, etc.

The non-swappable part will be tricky. One doesn't know how many
threads will be created in a process. This mechanism shouldn't put an
arbitrary limit in place. So where to allocate the memory? Perhaps
it's better to implicitly mark the memory page pointed to by the new
syscall as non-swappable? This could mean one page per thread...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/