lkml.org 
[lkml]   [2004]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Slab cache reap and CPU availability
    Dimitri Sivanich <sivanich@sgi.com> wrote:
    >
    > Hi all,
    >
    > I have a fairly general question about the slab cache reap code.
    >
    > In running realtime noise tests on the 2.6 kernels (spinning to detect periods
    > of CPU unavailability to RT threads) on an IA/64 Altix system, I have found the
    > cache_reap code to be the source of a number of larger holdoffs (periods of
    > CPU unavailability). These can last into the 100's of usec on 1300 MHz CPUs.
    > Since this code runs periodically every few seconds as a timer softirq on all
    > CPUs, holdoffs can occur frequently.
    >
    > Has anyone looked into less interruptive alternatives to running cache_reap
    > this way (for the 2.6 kernel), or maybe looked into potential optimizations
    > to the routine itself?
    >

    Do you have stack backtraces? I thought the problem was via the RCU
    softirq callbacks, not via the timer interrupt. Dipankar spent some time
    looking at the RCU-related problem but solutions are not comfortable.

    What workload is triggering this?
    -
    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.030 / U:0.304 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site