[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070214200347.GK32271@kvack.org>
Date: Wed, 14 Feb 2007 15:03:47 -0500
From: Benjamin LaHaise <bcrl@...ck.org>
To: Davide Libenzi <davidel@...ilserver.org>
Cc: Russell King <rmk+lkml@....linux.org.uk>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.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>,
Suparna Bhattacharya <suparna@...ibm.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch 06/11] syslets: core, documentation
On Wed, Feb 14, 2007 at 11:45:23AM -0800, Davide Libenzi wrote:
> Sort of, except that the whole thing can complete syncronously w/out
> context switches. The real point of the whole fibrils/syslets solution is
> that kind of optimization. The solution is as good as it is now, for
Except that You Can't Do That (tm). Try to predict beforehand if the code
path being followed will touch the FPU or SSE state, and you can't. There is
no way to avoid the context switch overhead, as you have to preserve things
so that whatever state is being returned to the user is as it was. Unless
you plan on resetting the state beforehand, but then you have to call into
arch specific code that ends up with a comparable overhead to the context
switch.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <dont@...ck.org>.
-
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