On Wed, 30 May 2007, Jeff Garzik wrote: > > You snipped the key part of my response, so I'll say it again: > > Event rings (a) most closely match what is going on in the hardware and (b) > often closely match what is going on in multi-socket, event-driven software > application.
I have rather strong counter-arguments: (a) yes, it's how hardware does it, but if you actually look at hardware, you quickly realize that every single piece of hardware uses a *different* ring interface. This should really tell you something. In fact, it may not be rings at all, but structures with more complex formats (eg the USB descriptors). (b) yes, event-driven software tends to use some data structures that are sometimes approximated by event rings, but they all use *different* software structures. There simply *is* no common "event" structure: each program tends to have its own issues, it's own allocation policies, and its own "ring" structures. They may not be rings at all. They can be priority queues/heaps or other much more complex structures. > To echo Uli and paraphrase an ad, "it's the interface, silly." THERE IS NO INTERFACE! You're just making that up, and glossing over the most important part of the whole thing! If you could actually point to something specific that matches what everybody needs, and is architecture-neutral, it would be a different issue. As is, you're just saying "memory-mapped interfaces" without actually going into enough detail to show HOW MUCH IT SUCKS. There really are very few programs that would use them. We had a trivial benchmark, the only function of which was to show usage, and here Ingo and Evgeniy are (once more) talking about bugs in that one months later. THAT should tell you something. Make poll/select/aio/read etc faster. THAT is where the payoffs are. In fact, if somebody wants to look at a standard interface that could be speeded up, the prime thing to look at is "readdir()" (aka getdents). Making _that_ thing go faster and scale better and do read-ahead is likely to be a lot more important for performance. It was one of the bottle-necks for samba several years ago, and nobody has really tried to improve it. And yes, that's because it's hard - people would rather make up new interfaces that are largely irrelevant even before they are born, than actually try to improve important existing ones. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/