Messages in this thread | | | Date | Sat, 14 Aug 2004 10:57:31 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6 |
| |
* Florian Schmidt <mista.tapas@gmx.net> wrote:
> This is something i wanted to ask anyways: In one of your first VP > announcements you mentioned you wanted to eliminate all latencies > 1 > ms. To me it seems, that that goal is pretty much reached [at least i > don't see any longer ones except for at boot and shutdown]. So the > question is: What is the lower limit for laterncies that you want to > hear reports about?
well ... i'm interested in all latencies that are well above the typical average latencies in the system. E.g. when the average is around 20-30 usecs then reports of 200-300 usecs would be interesting.
there's no hard limit, really. Also, sometimes latencies that are 0.3 msec in the report could be 3 msec if triggered properly. So a seemingly lower than 1 msec latency can very well pinpoint a problem area.
> WRT mlockall: i tried mlockall'ing 500 megs. This produced a new max > latency of 299 us. the trace is rather long. This one is with jackd > running and the one below this is w/o jackd running:
> 0.010ms (+0.000ms): free_page_and_swap_cache (clear_page_tables) > 0.010ms (+0.000ms): __page_cache_release (clear_page_tables) > 0.010ms (+0.000ms): free_hot_page (clear_page_tables)
hm, the reason for this one is that clear_page_tables() does all the freeing in a single uninterrupted critical section covered by mm->page_table_lock.
This function needs a lock-break i believe. Especially in the process-exit case (exit_mmap()) the lock seems unjustified - the current task is the sole owner of a never-to-be-used-again collection of pagetables.
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/
| |