[lkml]   [2003]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: userspace irq balancer
    Again, since the userland is using /proc/irq/N/smp_affinity, the in-kernel one won't touch whatever settings done by the userlannd. So I don't think we have issues here - if the userland has more knowledge, then it simply uses binding. If not, use the generic but dumb one in the kernel. Same thing as scheduling. If the dumb one has a critical problem, we should fix it.

    At the same time, I don't believe a single almighty userland policy exists, either. One might need to write or modify his program to do the best for the system anyway. Or a very simple script might just work fine.

    > -----Original Message-----
    > From: James Cleverdon []
    > Sent: Wednesday, May 21, 2003 7:27 AM
    > To: David S. Miller;
    > Cc:;;;
    > Subject: Re: userspace irq balancer
    > On Tuesday 20 May 2003 05:22 pm, David S. Miller wrote:
    > > From: Andrew Morton <>
    > > Date: Tue, 20 May 2003 02:17:12 -0700
    > >
    > > Concerns have been expressed that the /proc interface may be a bit
    > racy.
    > > One thing we do need to do is to write a /proc stresstest tool which
    > > pokes numbers into the /proc files at high rates, run that under traffic
    > > for a few hours.
    > >
    > > This issue is %100 independant of whether policy belongs in the
    > > kernel or not. Also, the /proc race problem exists and should be
    > > fixed regardless.
    > >
    > > Nobody has tried improving the current balancer.
    > >
    > > Policy does not belong in the kernel. I don't care what algorithm
    > > people decide to use, but such decisions do NOT belong in the kernel.
    > You keep saying that, but suppose I want to try HW IRQ balancing using the
    > TPR
    > registers. How could I do that from userspace? And if I could, wouldn't
    > the
    > benefit of real time IRQ routing be lost?
    > It seems to me that only long term interrupt policy can be done from
    > userland.
    > Anything that does fast responses to fluctuating load must be inside the
    > kernel.
    > At the moment we don't do any fast IRQ policy. Even the original
    > irq_balance
    > only looked for idle CPUs after an interrupt was serviced. However,
    > suppose
    > you had a P4 with hyperthreading turned on. If an IRQ is to be delivered
    > to
    > the main thread but it is busy and its sibling is idle, why shouldn't we
    > deliver the interrupt to the idle sibling? They both share the same
    > caches,
    > etc, so cache warmth isn't a problem.
    > --
    > James Cleverdon
    > IBM xSeries Linux Solutions
    > {jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com
    > -
    > 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
    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.031 / U:122.424 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site