[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070222151509.GA13670@elte.hu>
Date: Thu, 22 Feb 2007 16:15:09 +0100
From: Ingo Molnar <mingo@...e.hu>
To: David Miller <davem@...emloft.net>
Cc: johnpol@....mipt.ru, arjan@...radead.org, drepper@...hat.com,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
hch@...radead.org, akpm@....com.au, alan@...rguk.ukuu.org.uk,
zach.brown@...cle.com, suparna@...ibm.com, davidel@...ilserver.org,
jens.axboe@...cle.com, tglx@...utronix.de
Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
* David Miller <davem@...emloft.net> wrote:
> The pushback to the primary thread you speak of is just extra work in
> my mind, for networking. Better to just begin operations and sit in
> the primary thread(s) waiting for events, and when they arrive push
> the operations further along using non-blocking writes, reads, and
> accept() calls. There is no blocking context really needed for these
> kinds of things, so a mechanism that tries to provide one is a waste.
one question is, what is cheaper, to block out of a read and a write and
to set up the event notification and then to return to the user context,
or to just stay right in there with all the context already constructed
and on the stack, and schedule away and then come back and queue back to
the primary thread once the condition the thread is waiting for is done?
The latter isnt all that unattractive in my mind, because it always does
forward progress, with minimal 'backout' costs.
furthermore, in a real webserver there's a whole lot of other stuff
happening too: VFS blocking, mutex/lock blocking, memory pressure
blocking, filesystem blocking, etc., etc. Threadlets/syslets cover them
/all/ and never hold up the primary context: as long as there's more
requests to process, they will be processed. Plus other important
networked workloads, like fileservers are typically on fast LANs and
those requests are very much a fire-and-forget matter most of the time.
in any case, this definitely needs to be measured.
Ingo
-
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