Re: [1/1] CBUS: new very fast (for insert operations) message bus based on kenel connector.

[Andrew Morton <akpm@osdl.org>]

Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
>
> Andrew, CBUS is not intended to be faster than connector itself, 
>  it is just not possible, since it calls connector's methods
>  with some preparation, which takes time.

Right - it's simply transferring work from one place to another.

>  CBUS was designed to provide very fast _insert_ operation.

I just don't see any point in doing this.  If the aggregate system load is
unchanged (possibly increased) then why is cbus desirable?

The only advantage I can see is that it permits irq-context messaging.

>  It is needed not only for fork() accounting, but for any
>  fast path, when we do not want to slow process down just to
>  send notification about it, instead we can create such a notification,
>  and deliver it later.

And when we deliver it later, we slow processes down!

>  Why do we defer all work from HW IRQ into BH context?

To enable more interrupts to come in while we're doing that work.

>  Because while we are in HW IRQ we can not perform other tasks,
>  so with connector and CBUS we have the same situation.

I agree that being able to send from irq context would be handy.  If we had
any code which wants to do that, and at present we do not.

But I fail to see any advantage in moving work out of fork() context, into
kthread context and incurring additional context switch overhead.  Apart
from conceivably better CPU cache utilisation.

The fact that deferred delivery can cause an arbitrarily large backlog and,
ultimately, deliberate message droppage or oom significantly impacts the
reliability of the whole scheme and means that well-designed code must use
synchronous delivery _anyway_.  The deferred delivery should only be used
from IRQ context for low-bandwidth delivery rates.

>  While we are sending a low priority event, we stops actuall work,
>  which is not acceptible in many situations.

Have you tested the average forking rate on a uniprocessor machine with
this patch?  If the forking continues for (say) one second, does the patch
provide any performance benefit?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/