[lkml]   [2001]   [Oct]   [3]   [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

    On Wed, 3 Oct 2001, jamal wrote:

    > this code was added by Robert to check something; cant remember the
    > details on that specific date. [...]


    > > + while (!list_empty(&queue->poll_list)) {
    > > + struct net_device *dev;
    > > [...]
    > > + if (dev->quota <= 0 || dev->poll(dev, &budget)) {
    > > + local_irq_disable();
    > > + list_del(&dev->poll_list);
    > > + list_add_tail(&dev->poll_list, &queue->poll_list);

    > You misunderstood. This is to enforce fairness. [...]

    (i did not criticize the list_add/list_del in any way, it's obviously
    correct to cycle the polled devices. I highlited that code only to show
    that the current patch as-is polls too agressively for generic server

    > Read the paper.

    (i prefer source code. Can i assume the 'authorative' patch to be the one
    with the "goto not_done;" line removed, correct?)

    > > 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.

    > The interupt just flags "i, netdev, have work to do"; [...]

    (and the only thing i pointed out was that the patch as-is did not limit
    the amount of polling done.)

    > > *if* you can make polling a success in ~90% of the time we enter
    > > tulip_poll() under non-specific server load (ie. not routing), then i
    > > think you have really good metrics.
    > we can make it 100% successful; i mentioned that we only do work, if
    > there is work to be done.

    can you really make it 100% successful for rx? Ie. do you only ever call
    the ->poll() function if there is a new packet waiting? How do you know
    with a 100% probability that someone on the network just sent a new packet
    waiting? (without receiving an interrupt to begin with that is.)


    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:03    [W:4.530 / U:0.392 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site