Re: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6

[Ingo Molnar <mingo@elte.hu>]

* 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