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 20:17:21 +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:05:13AM -0800, Davide Libenzi (davidel@...ilserver.org) wrote:
> On Thu, 15 Feb 2007, Linus Torvalds wrote:
> 
> > I don't think the "atom" approach is bad per se. I think it could be fine 
> > to have some state information in user space. It's just that I think 
> > complex interfaces that people largely won't even use is a big mistake. We 
> > should concentrate on usability first, and some excessive cleverness 
> > really isn't a big advantage.
> > 
> > Being able to do a "open + stat" looks like a fine thing. But I doubt 
> > you'll see a lot of other combinations.
> 
> 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.

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.

> Actually, there is a difference. The standard multithreaded function is 
> easier to code in C than with the complex atoms chains. The number of 
> service thread becomes suddendly proportional to the number of active 
> sessions.
> The more I look at this, the more I think that async_submit should submit 
> simple syscalls, or an array of them (unrelated/parallel).
 
That is the case - atom items (I do hope that this subsystem would be
able to perform not only syscalls, but any kernel interfaces suitable
prototypes, v2 seems to move that direction) are called asynchronously 
from main userspace thread to achieve the maximum performance.
 
> - 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/