Michael et al, Ok, I redid my failed "hybrid mode" patch from scratch (original patch never sent out, I never got it to a working point). Having learnt from my mistake, this time instead of trying to mix the old and the new code, instead I just extended the new code, and wrote a _lot_ of comments about it. I also made it configurable, using a "page_lock_unfairness" knob, which this patch defaults to 1000 (which is basically infinite). That's just a value that says how many times we'll try the old unfair case, so "1000" means "we'll re-queue up to a thousand times before we say enough is enough" and zero is the fair mode that shows the performance problems. I've only (lightly) tested those two extremes, I think the interesting range is likely in the 1-5 range. So you can do echo 0 > /proc/sys/vm/page_lock_unfairness .. run test .. and you should get the same numbers as without this patch (within noise, of course). Or do echo 5 > /proc/sys/vm/page_lock_unfairness .. run test .. and get numbers for "we accept some unfairness, but if we have to requeue more than five times, we force the fair mode". Again, the default is 1000, which is ludicrously high (it's not a "this many retries per page" count, it's a "for each waiter" count). I made it that high just because I have *not* run any numbers for that interesting range, I just checked the extreme cases, and I wanted to make sure that Michael sees the old performance (modulo other changes to 5.9, of course). Comments? The patch really has a fair amount of comments in it, in fact the code changes are reasonably small, most of the changes really are about new and updated comments about what is going on. I was burnt by making a mess of this the first time, so I proceeded more thoughtfully this time. Hopefullyt the end result is also better. (Note that it's a commit and has a SHA1, but it's from my "throw-away tree for testing", so it doesn't have my sign-off or any real commit message yet: I'll do that once it gets actual testing and comments). Linus