[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200801100904.46842.rusty@rustcorp.com.au>
Date: Thu, 10 Jan 2008 09:04:45 +1100
From: Rusty Russell <rusty@...tcorp.com.au>
To: Zach Brown <zach.brown@...cle.com>
Cc: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Ulrich Drepper <drepper@...hat.com>,
Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@....com.au>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Evgeniy Polyakov <johnpol@....mipt.ru>,
"David S. Miller" <davem@...emloft.net>,
Suparna Bhattacharya <suparna@...ibm.com>,
Davide Libenzi <davidel@...ilserver.org>,
Jens Axboe <jens.axboe@...cle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Dan Williams <dan.j.williams@...il.com>,
Jeff Moyer <jmoyer@...hat.com>,
Simon Holm Thogersen <odie@...aau.dk>,
suresh.b.siddha@...el.com
Subject: Re: [PATCH 5/6] syslets: add generic syslets infrastructure
On Thursday 10 January 2008 05:16:57 Zach Brown wrote:
> > The latter. A ring is optimal for processing a huge number of requests,
> > but if you're really going to be firing off syslet threads all over the
> > place you're not going to be optimal anyway. And being able to point the
> > return value to the stack or into some datastructure is way nicer to code
> > (zero setup == easy to understand and easy to convert).
>
> One of Linus' rhetorical requirements for the syslets work is that we be
> able to wait for the result without spending overhead building up state
> in some completion context. The userland rings in the current syslet
> patches achieve that and don't seem outrageously complicated.
I'd have to read his original statement, but eventfd doesn't build up state,
so I think it qualifies.
YA incompatible userspace notification system just doesn't excite me though.
Cheers,
Rusty.
--
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