From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755622AbbINPZn (ORCPT ); Mon, 14 Sep 2015 11:25:43 -0400 Received: from g1t6214.austin.hp.com ([15.73.96.122]:34078 "EHLO g1t6214.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbbINPZk (ORCPT ); Mon, 14 Sep 2015 11:25:40 -0400 Message-ID: <55F6E6F2.10102@hpe.com> Date: Mon, 14 Sep 2015 11:25:38 -0400 From: Waiman Long User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12 MIME-Version: 1.0 To: Davidlohr Bueso CC: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Scott J Norton , Douglas Hatch Subject: Re: [PATCH v6 4/6] locking/pvqspinlock: Collect slowpath lock statistics References: <1441996658-62854-1-git-send-email-Waiman.Long@hpe.com> <1441996658-62854-5-git-send-email-Waiman.Long@hpe.com> <20150911231355.GD19736@linux-q0g1.site> In-Reply-To: <20150911231355.GD19736@linux-q0g1.site> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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