svn commit: r265792 - head/sys/kern

[Alexander Motin]

On 26.08.2014 21:54, Slawa Olhovchenkov wrote:
> On Tue, May 20, 2014 at 09:04:25AM -0700, Adrian Chadd wrote:
> 
>> On 20 May 2014 08:41, Slawa Olhovchenkov <slw at zxy.spb.ru> wrote:
>>
>>>> (But if you try it on 10.0 and it changes things, by all means let me know.)
>>>
>>> I am try on 10.0, but not sure about significant improvement (may be
>>> 10%).
>>>
>>> For current CPU (E5-2650 v2 @ 2.60GHz) hwpmc don't working (1. after
>>> collect some data `pmcstat -R sample.out -G out.txt` don't decode any;
>>> 2. kldunload hwpmc do kernel crash) and I can't collect detailed
>>> profile information.
>>
>> Yup. I'm starting to get really ticked off at how pmc logging on
>> multi-core devices just "stops" after a while. I'll talk with other
>> pmc people and see if we can figure out what the heck is going on. :(
> 
> Now I can test you work on CPU w/ working pmc.
> @ CPU_CLK_UNHALTED_CORE [241440 samples]
> 
> 10.59%  [25561]    _mtx_lock_spin_cookie @ /boot/kernel/kernel
>  94.25%  [24092]     pmclog_reserve @ /boot/kernel/hwpmc.ko
>   100.0%  [24092]      pmclog_process_callchain
>    100.0%  [24092]       pmc_process_samples
>     100.0%  [24092]        pmc_hook_handler
>      100.0%  [24092]         hardclock_cnt @ /boot/kernel/kernel

Slava, on large SMP systems you should specify some much bigger division
rate (like `-n 100000000`) when doing PMC sampling. Otherwise you are
mostly measuring PMC's internal lock congestion.

-- 
Alexander Motin