[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
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
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 :(
Main Index |
Thread Index |