linux-kernel - Re: [patch 05/11] syslets: core code

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:	Thu, 15 Feb 2007 21:01:18 +0300
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	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>,
	Ulrich Drepper <drepper@...hat.com>,
	Zach Brown <zach.brown@...cle.com>,
	"David S. Miller" <davem@...emloft.net>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 05/11] syslets: core code

On Thu, Feb 15, 2007 at 09:39:33AM -0800, Davide Libenzi (davidel@...ilserver.org) wrote:
> On Thu, 15 Feb 2007, Evgeniy Polyakov wrote:
> 
> > On Thu, Feb 15, 2007 at 09:05:13AM -0800, Davide Libenzi (davidel@...ilserver.org) wrote:
> > > 
> > > I actually think that building chains of syscalls bring you back to a 
> > > multithreaded solution. Why? Because suddendly the service thread become 
> > > from servicing a syscall (with possible cachehit optimization), to 
> > > servicing a whole session. So the number of service threads needed (locked 
> > > down by a chain) becomes big because requests goes from being short-lived 
> > > syscalls to long-lived chains of them. Think about the trivial web server, 
> > > and think about a chain that does open->fstat->sendhdrs->sendfile after an 
> > > accept. What's the difference with a multithreaded solution that does 
> > > accept->clone and execute the above code in the new thread? Nada, NIL.
> > 
> > That is more ideological question about micro-thread design at all.
> > If syslet will be able to perform only one syscall, one will have 4
> > threads for above case, not one, so it is even more broken.
> 
> Nope, just one thread. Well, two, if you consider the "main" dispatch 
> thread, and the syscall service thread.
 
Argh, if they are supposed to run synchronously, for example stat can be
done in parallel with sendfile in above example, but generally yes, one
execution thread.
 
> > So, if Linux moves that way of doing AIO (IMO incorrect, I think that
> > the correct state machine made not of syscalls, but specially crafted
> > entries - like populate pages into VFS, send chunk, recv chunk without
> > blocking and continue on completion and the like), syslets with attached 
> > state machines are the (smallest evil) best choice.
> 
> But at that point you don't need to have complex atom interfaces, with 
> chains, whips and leather pants :) Just code it in C and submit that to 
> the async engine. The longer is the chain though, the closer you get to a 
> fully multithreaded solution, in terms of service thread consuption. And 
> what do you save WRT a multithreaded solution? Not thread 
> creation/destroy, because that cost is fully amortized inside the chain 
> execution cost (plus a pool would even save that).
> IMO the plus of a generic async engine is mostly from a kernel code 
> maintainance POV. You don't need anymore to have AIO-aware code paths, 
> that automatically transalte to smaller and more maintainable code.
 
It is completely possible to not wire up several syscalls and just use
only one per async call, but _if_ such a requirement rises, the whole
infrastructure is there. 
 
> - Davide
> 

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