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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Feb 2007 15:15:18 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	Ulrich Drepper <drepper@...hat.com>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.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>,
	Zach Brown <zach.brown@...cle.com>,
	"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: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

* Evgeniy Polyakov <johnpol@....mipt.ru> wrote:

> > your whole reasoning seems to be faith-based:
> > 
> > [...] Anyway, kevents are very small, threads are very big, [...]
> > 
> > How about following the scientific method instead?
> 
> That are only rethorical words as you have understood I bet, I meant 
> that the whole process of getting readiness notification from kevent 
> is way tooo much faster than resheduling of the new process/thread to 
> handle that IO.
> 
> The whole process of switching from one process to another can be as 
> fast as bloody hell, but all other details just kill the thing.

for our primary abstractions there /IS NO OTHER DETAIL/ but wakeup and 
context-switching! The "event notification" of a sys_read() /IS/ the 
wakeup and context-switching that we do - or the epoll/kevent enqueueing 
as an alternative.

yes, the two are still different in a number of ways, and yes, it's 
still stupid to do a pool of thousands of threads and thus we can always 
optimize queuing, RAM and cache footprint via specialization, but your 
whole foundation seems to be constructed around the false notion that 
queueing and scheduling a task by the scheduler is somehow magically 
expensive and different from queueing and scheduling other type of 
requests. Please reconsider that foundation and open up a bit more to a 
slightly different world view: scheduling is really just another, more 
generic (and thus certainly more expensive) type of 'request queueing', 
and user-space, most of the time, is much better off if it handles its 
'requests' and 'events' via tasks. (Especially if many of those 'events' 
turn out to be non-events at all, so to speak.)

	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/