[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.98.0705300820350.26602@woody.linux-foundation.org>
Date: Wed, 30 May 2007 08:31:51 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jeff Garzik <jeff@...zik.org>
cc: Ingo Molnar <mingo@...e.hu>, Zach Brown <zach.brown@...cle.com>,
linux-kernel@...r.kernel.org,
Arjan van de Ven <arjan@...radead.org>,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@....com.au>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Ulrich Drepper <drepper@...hat.com>,
Evgeniy Polyakov <johnpol@....mipt.ru>,
"David S. Miller" <davem@...emloft.net>,
Suparna Bhattacharya <suparna@...ibm.com>,
Davide Libenzi <davidel@...ilserver.org>,
Jens Axboe <jens.axboe@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Syslets, Threadlets, generic AIO support, v6
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists