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.0701302153520.3611@woody.linux-foundation.org>
Date:	Tue, 30 Jan 2007 22:06:48 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	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 Wed, 31 Jan 2007, Nick Piggin wrote:
> 
> I always thought that the AIO people didn't do this because they wanted
> to avoid context switch overhead.

I don't think that scheduling overhead was ever a really the reason, at 
least not the primary one, and at least not on Linux. Sure, we can 
probably make cooperative thread switching a bit faster than even 
VM-sharing thread switching (maybe), but it's not going to be *that* big 
an issue.

Ifaik, the bigger issues were about setup costs (but also purely semantic 
- it was hard to do AIO semantics with threads).

And memory costs. The "one stack page per outstanding AIO" may end up 
still being too expensive, but threads were even more so.

[ Of course, that used to also be the claim by all the people who thought 
  we couldn't do native kernel threads for "normal" threading either, and 
  should go with the n*m setup. Shows how much they knew ;^]

But I've certainly _personally_ always wanted to do AIO with threads. I 
wanted to do it with regular threads (ie the "clone()" kind). It didn't 
fly. But I think we can possibly lower both the setup costs and the memory 
costs with the cooperative approach, to the point where maybe this one is 
more palatable and workable.

And maybe it also solves some of the scalability worries (threads have ID 
space and scheduling setup things that essentially go away by just not 
doing them - which is what the fibrils simply wouldn't have).

(Sadly, some of the people who really _use_ AIO are the database people, 
and they really only care about a particularly stupid and trivial case: 
pure reads and writes. A lot of other loads care about much more complex 
things: filename lookups etc, that traditional AIO cannot do at all, and 
that you really want something more thread-like for. But those other loads 
get kind of swamped by the DB needs, which are might tighter and trivial 
enough that you don't "need" a real thread for them).

		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/