[lkml]   [2004]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] RCU for low latency (experimental)
    On Tue, Mar 23, 2004 at 06:10:02PM +0530, Dipankar Sarma wrote:
    > On Tue, Mar 23, 2004 at 01:31:05PM +0100, Andrea Arcangeli wrote:
    > > On Tue, Mar 23, 2004 at 11:35:06AM +0100, Arjan van de Ven wrote:
    > > >
    > > > > Reduce bh processing time of rcu callbacks by using tunable per-cpu
    > > > > krcud daemeons.
    > > >
    > > > why not just use work queues ?
    > >
    > > I don't know if work queues are scheduler friendly, but definitely the
    > > rearming tasklets are. Running a dozen callbacks per pass and queueing
    > > any remining work to a rearming tasklet should fix it.
    > One problem that likely happen here is that under heavy interrupt
    > load, large number of softirqs still starve out user processes.

    Disagree, run 1 callback per tasklet and then you will not measure the
    cost of this callback compared to the cost of talking to the hardware
    entering/exiting kernel etc...

    > In my DoS testing setup, I see that limiting RCU softirqs
    > and re-arming tasklets has no effect on user process starvation.

    in an irq flood load that stalls userspace anyways it's ok to spread the
    callback load into the irqs, 10 tasklets and in turn 10 callbacks per
    irqs or so. That load isn't scheduler friendly anyways.

    the one property you need is not to be RT like eventd, to be scheduler
    friendly, but guaranteed to make progress too and that's what softirqs
    can give you and that's why I used only softirqs in my rcu_poll
    patches too ;).
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:01    [W:0.081 / U:19.412 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site