Messages in this thread |  | | | Date | Mon, 16 Aug 2004 13:31:31 +0200 | | From | Ingo Molnar <> | | Subject | Re: [patch] voluntary-preempt-2.6.8.1-P1 |
| |
* Thomas Charbonnel <thomas@undata.org> wrote:
> Tested P1. The biggest offender on my system is still reiserfs' > search_by_key. The trace is made of a very long loop of : > 0.016ms (+0.000ms): reiserfs_in_journal (scan_bitmap_block) > 0.016ms (+0.000ms): find_next_zero_bit (scan_bitmap_block) > (...) > 0.977ms (+0.000ms): reiserfs_in_journal (scan_bitmap_block) > 0.977ms (+0.000ms): find_next_zero_bit (scan_bitmap_block) > with interrupts showing up in the trace from time to time. Do you have > plans to fix this, or should I switch to ext3 ?
i took a quick look and the reiserfs locking rules in that place do not seem to be easily fixable - this is the tree-lookup code which i suspect cannot be preempted. The reiser journalling code also makes use of the big kernel lock. I'd suggest reporting this to the reiserfs folks and (if it's not too much effort to migrate) use ext3 meanwhile.
> but the weird thing is that the latency sum goes way above those 100us, > the culprit being do_IRQ, regularly chewing up to 1ms !
> 0.011ms (+0.000ms): enable_8259A_irq (startup_8259A_irq) > 0.954ms (+0.943ms): do_IRQ (common_interrupt)
weird. This has the looks of a preempt-timing bug (we get a timer IRQ every 1 msec) - but there should be no preempt-timing when we are in the idle task (swapper).
> http://www.undata.org/~thomas/swapper.trace
i'll upload -P2 in a couple of minutes, it will trace the code that do_IRQ() interrupted too - that would be quite useful in your case.
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/
|  |