[lkml]   [2001]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5
    [ I hope not to reiterate the obvious, I didn't read every single email
    of this thread ]

    > > > In a generic computing environment i want to spend cycles doing useful
    > > > work, not polling. Even the quick kpolld hack [which i dropped, so please
    > > > dont regard it as a 'competitor' patch] i consider superior to this, as i
    > > > can renice kpolld to reduce polling. (plus kpolld sucks up available idle
    > > > cycles as well.) Unless i royally misunderstand it, i cannot stop the
    > > > above code from wasting my cycles, and if that is true i do not want to
    > > > see it in the kernel proper in this form.
    > On Wed, 3 Oct 2001, jamal wrote:
    > > The interupt just flags "i, netdev, have work to do"; [...]
    On Wed, Oct 03, 2001 at 06:51:55PM +0200, Ingo Molnar wrote:
    > (and the only thing i pointed out was that the patch as-is did not limit
    > the amount of polling done.)

    You're perfectly right that it's not ok for a generic computing
    environment to spend lots of cpu in polling, but it is clear that in a
    dedicated router/firewall we can just shutdown the NIC interrupt forever via
    disable_irq (no matter if the nic supports hw flow control or not, and
    in turn no matter if the kid tries to spam the machine with small
    packets) and dedicate 1 cpu to the polling-work with ksoftirqd polling
    forever the NIC to deliver maximal routing performance or something like
    that. ksoftirqd will ensure fairness with the userspace load as well.
    You probably wouldn't get a benefit with tux because you would
    potentially lose way too much cpu with true polling and you're traffic
    is mostly going from the server to the clients not the othet way around
    (plus the clients uses delayed acks etc..), but the world isn't just

    Of course we agree that such a "polling router/firewall" behaviour must
    not be the default but it must be enabled on demand by the admin via
    sysctl or whatever else userspace API. And I don't see any problem with

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