Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pool_cache_invalidate(9) (wrong?) semantic -- enable xcall invalidation



On Thu, 17 Nov 2011 23:08:28 -0600, David Young wrote:
On Fri, Nov 18, 2011 at 01:09:49AM +0100, Jean-Yves Migeon wrote:
- force all xcall(9) API consumers to pass dynamically allocated
arguments, a bit like workqueue(9) enqueues works. Scheduling
xcall(9) is now managed by a SIMPLEQ() of requests.

- extends softint(9) API so we can pass arguments to it as well as
the targetted CPU(s) (optional argument).

The last two points make me think that the softint(9), workqueue(9)
and xcall(9) APIs have a potential for unification; all of these are
somewhat redundant, they all schedule/signal/dispatch stuff to other
threads, albeit under different conditions though.

See "Kernel Continuations" in <http://www.netbsd.org/~matt/smpnet.html>.
IIRC, the document does not contemplate putting xcall(9) under
the proposed kernel-continuations framework, but it does mention
both softints and workqueues as candidates for unification under
continuations.

Interesting reading; and yes, it seems to be case. Cross calls and softints are functionally close: they dispatch works to other threads, but softint(9) cannot pass arguments whereas xcall(9) do. From an implementation PoV, xcall and sofint are CPU-bound threads nowadays, with additional strong requirements for softints (cannot sleep, lightweight, mapped to interrupt level priorities). xcall threads are just plain kernel threads.

The last part of the page is also worth a look. I remember a PoC on L4 kernels for "single/merge kernel stack" implementations, and matt's idea is close to this too.

Lots of ideas, so little time for me :(

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost


Home | Main Index | Thread Index | Old Index