Date: Thu, 22 Feb 2007 16:15:09 +0100
From: Ingo Molnar <mingo@elte.hu>
To: David Miller <davem@davemloft.net>
Cc: johnpol@2ka.mipt.ru, arjan@infradead.org, drepper@redhat.com,
       linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
       hch@infradead.org, akpm@zip.com.au, alan@lxorguk.ukuu.org.uk,
       zach.brown@oracle.com, suparna@in.ibm.com, davidel@xmailserver.org,
       jens.axboe@oracle.com, tglx@linutronix.de
Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
Message-ID: <20070222151509.GA13670@elte.hu>
References: <20070222123929.GA5208@2ka.mipt.ru> <20070222.054127.104035694.davem@davemloft.net> <20070222143145.GA3246@elte.hu> <20070222.064704.71093028.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070222.064704.71093028.davem@davemloft.net>
User-Agent: Mutt/1.4.2.2i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1761
Lines: 34


* David Miller <davem@davemloft.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/