[lkml]   [2003]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: userspace irq balancer
    On 19 May 2003, Dave Hansen wrote:

    > On Mon, 2003-05-19 at 15:11, Arjan van de Ven wrote:
    > But, do you see the need for ripping out the current code? For those of
    > us that are still running a slightly more primitive distro, it would be
    > nice to have some pretty effective default behavior, like what is in the
    > kernel now.

    Ripping out the current code and having useful default behaviour are
    hopefully not mutually exclusive.

    On 19 May 2003, David S. Miller wrote:

    > You have to install new modutils to even use modules with the 2.5.x
    > kernel, given that why are we even talking about the "inconvenience"
    > of installing the usermode IRQ balancer as being a blocker for
    > ripping out the in-kernel stuff?

    But you don't have to use modules at all, while running without
    interrupts isn't an option.

    > The in-kernel stuff MUST go. It went in because "some benchmark went
    > faster", but with no "why" describing why it might have improved
    > performance. We KNOW it absolutely sucks for routing and firewall
    > applications. The in-kernel bits were all a shamans dance, with zero
    > technical "here is why this makes things go faster" description
    > attached. If I remember properly, the changelog message when the
    > in-kernel irq balancing went in was of the form "this makes some
    > specweb run go faster".

    Perhaps I misread Linus' recent post about not breaking things to the
    user, and I know he was talking about executables in particular, but if
    this new code is so great, why can't it start with some default values
    which will be no worse than what we have? Because there will be people
    who haven't installed the latest userspace int-diddler.

    Deliberately making the initial tuning useless to promote use of the
    user space software seems counter productive. There will be many users
    who will find a way to make a tuned kernel worse than any default, so if
    the default is usable it will avoid people shooting themselves in the
    foot. Can you imagine someone leaving an interrupt unserviced at all? If
    there's a way someone will :-(

    I'm not defending the existing code, just speaking for the idea of
    leaving something useful in its place.

    On Tue, 20 May 2003, Andrew Theurer wrote:

    > If kirq gets ripped out, at least have some default policy that is somewhat
    > harmless, like destination cpu = int_number % nr_cpus. I think Suse8 had
    > this, and it performed reasonably well.

    As long as it's something sane, it doesn't have to be optimal. If SuSE
    used it, it's likely to be good enough.

    On Wed, 21 May 2003, Martin J. Bligh wrote:

    > I'd be happy with that - sounds to me like you're arguing for the same
    > thing. Sane default in kernel, can override from userspace if you like.
    > However, I've yet to see an implementation of the TPR usage that got
    > good performance numbers ... I'd love to see that happen.

    I may be misreading the intent in David's messages, as long as the
    default is useful it certainly doesn't have to be what is in place now.
    Of couse it would be useful to actually see some numbers, just because
    existing code is somewhat ugly, confusing, and ill-justified and the new
    is a pretty algorithm with great flexibility, does not mean that the
    actual benchmarks will reflect better performance.

    bill davidsen <>
    CTO, TMR Associates, Inc
    Doing interesting things with little computers since 1979.

    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 13:35    [W:0.024 / U:6.016 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site