lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55F6E6F2.10102@hpe.com>
Date:	Mon, 14 Sep 2015 11:25:38 -0400
From:	Waiman Long <waiman.long@....com>
To:	Davidlohr Bueso <dave@...olabs.net>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, Scott J Norton <scott.norton@...com>,
	Douglas Hatch <doug.hatch@...com>
Subject: Re: [PATCH v6 4/6] locking/pvqspinlock: Collect slowpath lock statistics

On 09/11/2015 07:13 PM, Davidlohr Bueso wrote:
> On Fri, 11 Sep 2015, Waiman Long wrote:
>
>> A sample of statistics counts after system bootup (with vCPU
>> overcommit) was:
>>
>> hash_hops_count=9001
>> kick_latencies=138047878
>> kick_unlock_count=9001
>> kick_wait_count=9000
>> spurious_wakeup=3
>> wait_again_count=2
>> wait_head_count=10
>> wait_node_count=8994
>> wake_latencies=713195944
>
> Any reason you chose not to make the stats per-cpu? The locking
> numbers don't have to be exact, so you can easily get away with
> it and suffer from much less overhead that resorting to atomics.
> Obviously assuming that reading/collecting the stats is done
> infrequently, such as between workloads or at bootup as you did.
>
> Thanks,
> Davidlohr

You can't use debugfs if we want to have per-cpu stats. We will have to 
use sysfs instead. This will require more code changes. It is certainly 
doable, but we have to choose between simplicity and performance 
overhead. Right now, I am assuming that lock PV lockstat is used 
primarily for debugging purpose and won't be enabled on production 
system. If we want to have this capability in production systems, we 
will certainly need to change it to per-cpu stats and use sysfs instead.

The original PV ticketlock code used debugfs and I was just following 
its footstep. Do you think it is worthwhile to have this capability 
available on production system by default?

Cheers,
Longman

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ