Messages in this thread | | | Date | Fri, 21 May 2004 19:16:09 -0700 | From | Andrew Morton <> | Subject | Re: 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/
| |