![]() | |||||||||||
Messages in this thread |
Andrea Arcangeli wrote: > On Tue, Mar 13, 2007 at 04:11:02PM +1100, Nick Piggin wrote: > >>Hi Anton, >> >>Very cool. Yeah I had come to the conclusion that it wasn't a kernel >>issue, and basically was afraid to look into userspace ;) > > > btw, regardless of what glibc is doing, still the cpu shouldn't go > idle IMHO. Even if we're overscheduling and trashing over the mmap_sem > with threads (no idea if other OS schedules the task away when they > find the other cpu in the mmap critical section), or if we've > overscheduling with futex locking, the cpu usage should remain 100% > system time in the worst case. The only explanation for going idle > legitimately could be on HT cpus where HT may hurt more than help but > on real multicore it shouldn't happen. > Well ignoring the HT issue, I was seeing lots of idle time simply because userspace could not keep up enough load to the scheduler. There simply were fewer runnable tasks than CPU cores. But it wasn't a case of all CPUs going idle, just most of them ;) -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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/ | ||||||||||
| Last update: 2007-03-13 11:09 [from the cache] ©2003-2008 | |||||||||||