Date:	Wed, 14 Feb 2007 15:13:17 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	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>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	"David S. Miller" <davem@...emloft.net>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 05/11] syslets: core code



On Wed, 14 Feb 2007, Ingo Molnar wrote:
> 
> i think you are banging on open doors. That async_stat() call is very 
> much what i'd like to see glibc to provide, not really the raw syslet 
> interface.

Right. Which is why I wrote (and you removed) the rest of my email.

If the "raw" interfaces aren't actually what you use, and you just expect 
glibc to translate things into them, WHY DO WE HAVE THEM AT ALL?

> The 'cost' of syslets is mostly the atom->next pointer in essence.

No. The cost is:

 - indirect interfaces are harder to follow and debug. It's a LOT easier 
   to debug things that go wrong when it just does what you ask it for, 
   instead of writing to memory and doing something totally obscure.

   I don't know about you, but I use "strace" a lot. That's the kind of 
   cost we have.

 - the cost is the extra and totally unnecessary setup for the 
   indirection, that nobody reallyis likely to use.

> The whole async infrastructure only takes up 20 nsecs more in the cached 
> case. (but with some crazier hacks i got the one-shot atom overhead 
> [compared to a simple synchronous null syscall] to below 10 nsecs, so 
> there's room in there for further optimizations. Our current null 
> syscall latency is around ~150 nsecs.)

You are not counting the whole setup cost there, then, because your setup 
cost is going to be at a minimum more expensive than the null system call.

And yes, for benchmarks, it's going to be done just once, and then the 
benchmark will loop a million times. But for other things like libraries, 
that don't know whether they get called once, or a million times, this is 
a big deal.

This is why I'd like a "async_stat()" to basically be the *same* cost as a 
"stat()". To within nanoseconds. WITH ALL THE SETUP! Because otherwise, a 
library may not be able to use it without thinking about it a lot, because 
it simply doesn't know whether the caller is going to call it once or many 
times.

THIS was why I wanted the "synchronous mode". Exactly because it removes 
all the questions about "is it worth it". If the cost overhead is 
basically zero, you know it's always worth it.

Now, if you make the "async_submit()" _incldue_ the setup itself (as you 
alluded to in one of your emails), and the cost of that is basically 
negligible, and it still allows people to do things simply and just submit 
a single system call without any real overhead, then hey, it's may be a 
complex interface, but at least you can _use_ it as a simple one.

At that point most of my arguments against it go away. It might still be 
over-engineered, but if the costs aren't visible, and it's obvious enough 
that the over-engineering doesn't result in subtle bugs, THEN (and only
then) is a more complex and generic interface worth it even if nobody 
actually ends up using it.

		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/

Powered by blists - more mailing lists