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.0702101034220.11630@alien.or.mcafeemobile.com>
Date:	Sat, 10 Feb 2007 10:45:28 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Linus Torvalds <torvalds@...ux-foundation.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 Fri, 9 Feb 2007, Linus Torvalds wrote:

> > Another, even simpler way IMO, is to just have a plain per-task kthread 
> > pool, and a queue.
> 
> Yes, that is actually quite doable with basically the same interface. It's 
> literally a "small decision" inside of "schedule_async()" on how it 
> actually would want to handle the case of "hey, we now have concurrent 
> work to be done".

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 I actually don't think a per-task kthread pool is necessarily a good 
> idea. If a thread pool works for this, then it should have worked for 
> regular thread create/destroy loads too - ie there really is little reason 
> to special-case the "async system call" case.

A per-process thread pool already has things correctly inherited, so we 
don't need to add special "adopt" routines for things like "files" and such.



> NOTE! I'm also not at all sure that we actually want to waste real threads 
> on this. My patch is in no way meant to be an "exclusive alternative" to 
> fibrils. Quite the reverse, actually: I _like_ those synchronous fibrils, 
> but I didn't like how Zach did the overhead of creating them up-front, 
> because I really would like the cached case to be totally *synchronous*.

I'm not advocating threads against fibrils. The use of threads may make 
things easier under certain POVs (less ad-hoc changes into mainline). The 
ideal would be to have a look at both and see Pros&Cons under different 
POVs (performance, code impact, etc..).



- Davide


-
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/