Messages in this thread | | | From | Dimitri Sivanich <> | Subject | Re: Slab cache reap and CPU availability | Date | Mon, 24 May 2004 10:39:39 -0500 (CDT) |
| |
> > 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? >
The IA/64 backtrace with all the cruft removed looks as follows:
0xa000000100149ac0 reap_timer_fnc+0x100 0xa0000001000f4d70 run_timer_softirq+0x2d0 0xa0000001000e9440 __do_softirq+0x200 0xa0000001000e94e0 do_softirq+0x80 0xa000000100017f50 ia64_handle_irq+0x190
The system is running mostly AIM7, but I've seen holdoffs > 30 usec with virtually no load on the system.
Which uncomfortable solutions (which could relate to this case) have been investigated?
Dimitri Sivanich <sivanich@sgi.com> - 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/
| |