lkml.org 
[lkml]   [2004]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRE: CONFIG_IRQBALANCE for AMD64?
    >> On Fri, May 28, 2004 at 10:46:18AM -0700, Martin J. Bligh wrote:
    >>>
    >>> Personally, I find the argument that it's hardware-specific control
    > code
    >>> a much better reason for it to belong in the kernel.
    >>
    >> Is it really hardware specific ??
    >
    > I think automatic IRQ binding business should belong to the user-level;
    > it can use generic statistics, application, or platform configuration
    > knowledge.
    >
    > The kernel-level should have some simple chipset model, such as lowest
    > priority delivery mode with finer granularity of control. The kirqd at
    > this point, is doing automatic IRQ binding business as well today,
    > although it does not literally bind them. So I think we need to remove
    > that part of code from kirqd.

    My personal feeling is that we can't get to happen from userspace what
    really needs to happen .... but we're going about this ass-backwards.
    Instead of starting with a solution, and seeing what we can wedge into
    it ... what do we actually want to do?

    Here's my start at a list ... I'm sure it's woefully incomplete.

    1. Utilize all CPUs roughly evenly for IRQ processing load (anything that's
    not measured by the scheduler at least, because it's unfair to other
    processes). Also, we may well have more than 1 CPU's worth of traffic to
    process in a large network server.

    2. Provide some sort of cache-affinity for network interrupt processing,
    which also helps us not get into out-of-order packet situations.

    3. Utilize idle CPUs where possible to shoulder the load.

    4. Provide such a solution for all architectures.

    What else? I think we started doing this because of (1 & 2) mainline,
    especially as the P4 is moronically stupid by default but I know Dave
    Olien looked at 3 as well at some point past.

    ISTR one of the objections to the in-kernel stuff was that the way it
    calculated costs was to look only at the in_interrupt() part of the
    processing ... does the backend stuff get accounted currently to the
    poor sucker who is currently running, in the same was as the interrupt?

    Whatever we do ... all arches are going to need to provide a way to direct
    interrupts to a certain CPU, or group thereof. Can they all do that already?
    I'll confess to not having looked at non-i386 arches. And are others as
    brain damaged as the P4? or do they do something round-robin by default?

    M.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:03    [W:0.025 / U:0.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site