Re: [PATCH] Instrumenting high latency

[Martin J. Bligh]

> This works very nicely standalone getting us this for example with the fixed patch:
> 
> 6ms non-preemptible critical section violated 1 ms preempt threshold starting at exit_mmap+0x1c/0x188 and ending at exit_mmap+0x118/0x188
>   [<c011d769>] dec_preempt_count+0x14f/0x151
>   [<c014d0d4>] exit_mmap+0x118/0x188
>   [<c014d0d4>] exit_mmap+0x118/0x188
>   [<c011df0a>] mmput+0x61/0x7b
>   [<c01226fa>] do_exit+0x142/0x510
>   [<c014c928>] unmap_vma_list+0xe/0x17
>   [<c0122b8a>] do_group_exit+0x41/0xf9
>   [<c0105fd5>] sysenter_past_esp+0x52/0x71
> 
> which then an objdump of the inlined code has allowed us to track it down to this:
> 
>           profile_exit_mmap(mm);
>           lru_add_drain();
> c014cfce:       e8 18 72 ff ff          call   c01441eb <lru_add_drain>
>           spin_lock(&mm->page_table_lock);
> c014cfd3:       e8 16 06 fd ff          call   c011d5ee <inc_preempt_count>
> 
> 
> That's pretty specific. I dont think this comes under the umbrella of statistics as such. Sure it can be modified to do it but I was looking for a tool to find where specific latency hotspots still exist. Of course I'm not capable myself of tackling the actual hotspots but those who code those areas certainly can tackle them knowing what firm data shows.

Guess so. Thought it might be nice to have a measurement of worst case
latencies across various functions ... I'll have a play with it, and see
if I can come up with something.

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/