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

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

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