Prev: Memory Compaction v7
Next: mm: Check if any page in a pageblock is reserved before marking it MIGRATE_RESERVE
From: Peter Zijlstra on 6 Apr 2010 11:00 On Tue, 2010-04-06 at 07:47 -0700, Ulrich Drepper wrote: > On Tue, Apr 6, 2010 at 01:48, Peter Zijlstra <peterz(a)infradead.org> > wrote: > > try > > spin > > try > > syscall > > This is available for a long time in the mutex implementation > (PTHREAD_MUTEX_ADAPTIVE_NP mutex type). It hasn't show much > improvement if any. There were some people demanding this support for > as far as I know they are not using it now. This is adaptive > spinning, learning from previous calls how long to wait. But it's > still unguided. There is no way to get information like "the owner > has been descheduled". That's where the FUTEX_LOCK thing comes in, it does all those, the above was a single spin loop to amortize the syscall overhead. I wouldn't make it any more complex than a single pause ins, syscalls are terribly cheap these days. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 10 Apr 2010 19:40
> 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... You only need one page per 4096 threads or so if you make it create the page on the first request, tied to say the signals and the like in threaded tasks, and you then allocate 'slots' in the page for future calls until you've got 4096 live. ie you'd see something like addr = set_tid_notifier_addr(); [1st call map page at x to x + 4095, probably R/O] [returns x] next thread addr = set_tid_notifier_addr() [returns x + 1] Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |