Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

[Linus Torvalds]

On Thu, 22 Feb 2007, Evgeniy Polyakov wrote:
> 
> My tests show that with 4k connections per second (8k concurrency) more 
> than 20k connections of 80k total block in tcp_sendmsg() over gigabit 
> lan between quite fast machines.

Why do people *keep* taking this up as an issue?

Use select/poll/epoll/kevent/whatever for event mechanisms. STOP CLAIMING 
that you'd use threadlets/syslets/aio for that. It's been pointed out over 
and over and over again, and yet you continue to make the same mistake, 
Evgeniy.

So please read that sentence ten times, and then don't continue to make 
that same mistake. PLEASE.

Event mechanisms are *superior* for events. But they *suck* for things 
that aren't events, but are actual code execution with random places that 
can block. THE TWO THINGS ARE TOTALLY AND UTTERLY INDEPENDENT!

Examples of events:
 - packet arrives
 - timer happens

Examples of things that are *not* "events":
 - filesystem lookup.
 - page faults

So the basic point is: for events, you use an event-based thing. For code 
execution, you use a thread-based thing. It's really that simple.

And yes, the two different things can usually be translated (at a very 
high cost in complexity *and* performance) into each other, so people who 
look at it as purely a theoretical exercise may think that "events" and 
"code execution" are equivalent. That's a very very silly and stupid way 
of looking at things in real life, though.

Yes, you can turn things that are better seen as threaded execution into 
an event-based thing by turning it into a state machine. And usually that 
is a TOTAL DISASTER, and the end result is fragile and impossible to 
maintain.

And yes, you can often (more easily) turn an event-based mechanism into a 
thread-based one, and usually the end result is a TOTAL DISASTER because 
it doesn't scale very well, and while it may actually result in somewhat 
simpler code, the overhead of managing ten thousand outstanding threads is 
just too high, when you compare to managing just a list of ten thousand 
outstanding events.

And yes, people have done both of those mistakes. Java, for example, 
largely did the latter mistake ("we don't need anything like 'select', 
because we'll just use threads for everything" - what a totally moronic 
thing to do!)

So Evgeniy, threadlets/syslets/aio is *not* a replacement for event 
queues. It's a TOTALLY DIFFERENT MECHANISM, and one that is hugely 
superior to event queues for certain kinds of things. Anybody who thinks 
they want to do pathname and inode lookup as a series of events is likely 
a moron. It's really that simple.

In a complex server (say, a database), you'd use both. You'd probably use 
events for doing the things you *already* use events for (whether it be 
select/poll/epoll or whatever): probably things like the client network 
connection handling.

But you'd *in*addition* use threadlets to be able to do the actual 
database IO in a threaded manner, so that you can scale the things that 
are not easily handled as events (usually because they have internal 
kernel state that the user cannot even see, and *must*not* see because of 
security issues).

So please. Stop this "kevents are better". The only thing you show by 
trying to go down that avenue is that you don't understand the 
*difference* between an event model and a thread model. They are both 
perfectly fine models and they ARE NOT THE SAME! They aren't even mutually 
incompatible - quite the reverse.

The thing people want to remove with threadlets is the internal overhead 
of maintaining special-purpose code like aio_read() inside the kernel, 
that doesn't even do all that people want it to do, and that really does 
need a fair amount of internal complexity that we could hopefully do with 
a more generic (and hopefully *simpler*) model.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/