[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47850F99.5020001@oracle.com>
Date: Wed, 09 Jan 2008 10:16:57 -0800
From: Zach Brown <zach.brown@...cle.com>
To: Rusty Russell <rusty@...tcorp.com.au>
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
>> Or do you mean the syscall return value ending up in the userspace
>> completion event ring? That's mostly about being able to wait for
>> pending syslets to complete.
>
> 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 have a hard time getting worked up about this particular piece of the
puzzle, though. If people are excited about *only* providing a pollable
fd to collect the syslet completions, well, great, whatever.
> This must be solved, yet all avenues seem crawling with worms.
Yup.
- z
--
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