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]

Message-ID: <Pine.LNX.4.64.0702280836080.12485@woody.linux-foundation.org>
Date:	Wed, 28 Feb 2007 08:42:27 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Davide Libenzi <davidel@...ilserver.org>
cc:	Ingo Molnar <mingo@...e.hu>, Ulrich Drepper <drepper@...hat.com>,
	Linux Kernel Mailing List <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>,
	Zach Brown <zach.brown@...cle.com>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

On Wed, 28 Feb 2007, Davide Libenzi wrote:
> 
> At this point, given how threadlets can be easily/effectively dispatched 
> from userspace, I'd argue the presence of either single/parallel or syslet 
> submission altogether. Threadlets allows you to code chains *way* more 
> naturally than syslets, and since they basically are like functions calls 
> in the fast path, they can be used even for single/parallel submissions. 

Well, I agree, except for one thing:
 - user space execution is *inherently* more expensive.

Why? Stack. Stack. Stack.

If you support threadlets with user space code, it means that you need a 
separate user-space stack for each threadlet. That's a potentially *big* 
cost to bear, both from a setup standpoint and from simply a memory 
allocation standpoint.

Quite frankly, I think threadlets are a great idea, but I think the lack 
of user-level footprint is *also* a great idea, and you should support 
both.

In short - the only thing I *don't* think is a great idea are those linked 
lists of atoms. I still think it's a pretty horrible interface, and I 
still don't think it really buys us very much. The only way it would buy 
us a lot is to change the linked lists dynamically (ie add new events at 
the end while old events are still executing), but quite frankly, that 
just makes the whole interface *even*worse* and just makes me have 
debugging nightmares (I'm also not even convinced it really would help 
us: we might avoid some costs of adding new events, but it would only 
avoid them for serial execution, and if the whole point of this is to 
execute things in parallel, that's a stupid thing to do).

So I would repeat my call for getting rid of the atoms, and instead just 
do a "single submission" at a time. Do the linking by running a threadlet 
that has user space code (and the stack overhead), which is MUCH more 
flexible. And do nonlinked single system calls without *either* atoms *or* 
a user-space stack footprint.

Please? 

What am I missing?

		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/