linux-kernel - Re: [PATCH 0 of 4] Generic AIO by scheduling stacks

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.0702101054250.8424@woody.linux-foundation.org>
Date:	Sat, 10 Feb 2007 11:01:49 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Davide Libenzi <davidel@...ilserver.org>
cc:	Zach Brown <zach.brown@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-aio@...ck.org, Suparna Bhattacharya <suparna@...ibm.com>,
	Benjamin LaHaise <bcrl@...ck.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 0 of 4] Generic AIO by scheduling stacks

On Sat, 10 Feb 2007, Davide Libenzi wrote:
> 
> For the queue approach, I meant the async_submit() to simply add the 
> request (cookie, syscall number and params) inside queue, and not trying 
> to execute the syscall. Once you're inside schedule, "stuff" has already 
> partially happened, and you cannot have the same request re-initiated by a 
> different thread.

But that makes it impossible to do things synchronously, which I think is 
a *major* mistake.

The whole (and really _only_) point of my patch was really the whole 
"synchronous call" part. I'm personally of the opinion that if you cannot 
handle the cached case as fast as just doing the system call directly, 
then the whole thing is almost pointless.

Things that take a long time we already have good methods for. "epoll" and 
"kevent" are always going to be the best way to handle the "we have ten 
thousand events outstanding". There simply isn't any question about it. 
You can *never* handle ten thousand long-running events efficiently with 
threads - even if you ignore all the CPU overhead, you're going to have a 
much bigger memory (and thus *cache*) footprint.

So anybody who wants to use AIO to do those kinds of long-running async 
things is out to lunch. It's not the point. 

You use the AIO stuff for things that you *expect* to be almost 
instantaneous. Even if you actually start ten thousand IO's in one go, and 
they all do IO, you would hopefully expect that the first ones start 
completingn before you've even submitted them all. If that's not true, 
then you'd just be better off using epoll.

Also, if you can make the cached case as fast as just doing the direct 
system call itself, that just changes the whole equation for using it. You 
suddenly don't have any downsides. You can start using the async 
interfaces in places you simply couldn't otherwise, or in places where 
you'd have to do a lot of performance tuning ("it makes sense under this 
particular load because I actually need to get 100 IO's going at the same 
time to saturate the disk").

So the "do cached things synchronously" really is important. Just because 
that makes a whole complicated optimization question go away: you 
basically *always* win for normal stuff.

		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/