Messages in this thread | | | Date | Fri, 3 Sep 2004 11:09:47 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q9 |
| |
* Ingo Molnar <mingo@elte.hu> wrote:
> > 00000002 0.002ms (+0.000ms): dummy_go_idle (schedule) > > 00000002 0.002ms (+0.060ms): schedule (io_schedule) > > 00000002 0.063ms (+0.069ms): load_balance_newidle (schedule) > > 00000002 0.133ms (+0.074ms): find_busiest_group (load_balance_newidle) > > 00000002 0.207ms (+0.034ms): find_next_bit (find_busiest_group) > > 00000002 0.242ms (+0.039ms): find_next_bit (find_busiest_group) > > 00000002 0.281ms (+0.070ms): find_busiest_queue (load_balance_newidle) > > 00000002 0.351ms (+0.071ms): find_next_bit (find_busiest_queue) > > 00000002 0.422ms (+0.069ms): double_lock_balance (load_balance_newidle) > > 00000003 0.492ms (+0.070ms): move_tasks (load_balance_newidle) > > this is as if the CPU executed everything in 'slow motion'. E.g. the > cache being disabled could be one such reason - or some severe DMA or > other bus traffic.
another thing: could you try maxcpus=1 again and see whether 1 CPU produces similar 'slow motion' traces? If it's DMA or PCI bus traffic somehow interfering then i'd expect the same phenomenon to pop up with a single CPU too. IIRC you tested an UP kernel once before, but i believe that was prior fixing all the latency measurement errors. Would be nice to re-test again, with maxcpus=1, and see whether any of these slow-motion traces trigger. On a 1-CPU test i'd suggest to lower the tracing threshold to half of the 2-CPU value.
Ingo - 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/
| |