Messages in this thread | | | From | Rusty Russell <> | Subject | Re: [PATCH] Futexes IV (Fast Lightweight Userspace Semaphores) | Date | Sat, 09 Mar 2002 15:49:35 +1100 |
| |
On Fri, 8 Mar 2002 11:22:20 -0800 (PST) Linus Torvalds <torvalds@transmeta.com> wrote: > First off, I have to say that I really like the current patch by Rusty. > The hashing approach is very clean, and it all seems quite good. As to > specific points:
Thanks. [Aside: VIRO PLEASE TAKE NOTE.]
> > (I) the fairness issues that have been raised. > > do you support two wakeup mechanism: FUTEX_UP and FUTEX_UP_FAIR > > or you don't care about fairness and starvation > > I don't think fairness and starvation is that big of a deal for > semaphores, usually being unfair in these things tends to just improve > performance through better cache locality with no real downside. That > said, I think the option should be open (which it does seem to be).
1) Unfairness definitely helps performance (~30% faster on tdbtorture and IIRC on Hubertus' benchmark too). 2) Absolute fairness depends on hardware anyway. 3) I was not able to produce any evidence of STARVATION (which I think we all agree *is* an issue).
So I'd say stick with the minimalistic, fast, unfair solution.
> For rwlocks, my personal preference is the fifo-fair-preference (unlike > semaphore fairness, I have actually seen loads where read- vs > write-preference really is unacceptable). This might be a point where we > give users the choice.
Yes. See post on "furwocks": fair-preference rw locks implemented in userspace on top of the futexes.
> I do think we should make the lock bigger - I worry that atomic_t simply > won't be enough for things like fair rwlocks, which might want a > "cmpxchg8b" on x86. > > So I would suggest making the size (and thus alignment check) of locks at > least 8 bytes (and preferably 16). That makes it slightly harder to put > locks on the stack, but gcc does support stack alignment, even if the code > sucks right now.
Actually, I disagree.
1) We've left wiggle room in the second arg to sys_futex() to add rwsems later if required. 2) Someone needs to implement them and prove they are superior to the pure userspace solution.
The most gain will be from a very briefly held lock that is 99.99% read. But if it's 10%, it's not worth it: we need numbers.
Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |