Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp738932ybi; Fri, 24 May 2019 10:37:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqwwUD5eD1ggdYlNc8AeCotWfDwJ38v2ONJJCe/+T/IplvXY1DumbeMk8Sk8GTz7Jj2zQvyt X-Received: by 2002:a17:902:848c:: with SMTP id c12mr58427495plo.17.1558719454988; Fri, 24 May 2019 10:37:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558719454; cv=none; d=google.com; s=arc-20160816; b=cyGN8VfwGX1I53WiY2VX6TnonA+TqWyDlPqzsvPKz8PzT6GVRuZxj0yt6y2TDGJSMd F+QpwGyB3/EUI2IlP7NxQrhrRjEbLS4/RqFWvEfD00qcsGVaHX/1+eZCkK5ybJpAOaCV bTFOpecp7TsWiwlK7YJoAbQg/UwGdbF+JGEWpiOSof/t+6VG5OyEwGpGvTxyp11GVYN+ hjYVUBv4EGZWEX/q+zC+OYQ4dl0lpC1xacKQ/FAz0Cl92NiI5GC88xLjl+/qfIGv97Y6 gwIvF4V/+7kcuda4Jl+viSJ3Yq3GEuSFuMQSWD8gk7WDezdQuzkjAWFBO4bcxnTbIHzo ViuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=E5D+RBT6McHAOp6MyPH+RGSGRUDBvImMbx+hl3m3CfU=; b=jTfj4wQPidk0dCGhc7x+m98VpVHAUqWz6lSRrTeP9ShAWn2bmz4YiJsGbeURhIyprU yBL1Rss++KfFcAcyqIn50Z/iv/5XZobhqXLKtXE6+AxrtDGJJqgz/zipC2cgB+UZxLcM 2F5JTt++xlJH3MlmJQSpqmgva/iJU4zLsdSZE6Qnld/iNN9e6pbggE7VVPwR8TLL1hoY oNpqpHtY+Prub1VZo+IIEclSymJEy2mPhm35VQMjQd6fjSLOBBepLblwXkqHZAQWyTvK v0Im2HGrqCnOmWld/Tv7OivGDcZEzXqkRlWK7LP8z+hN1k4MMvX2E81IKOxbTQuhaOMK Xktg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p188si5023036pfp.112.2019.05.24.10.37.19; Fri, 24 May 2019 10:37:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404141AbfEXRfv (ORCPT + 99 others); Fri, 24 May 2019 13:35:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34184 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404131AbfEXRfu (ORCPT ); Fri, 24 May 2019 13:35:50 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 533573084295; Fri, 24 May 2019 17:35:43 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-85.bos.redhat.com [10.18.17.85]) by smtp.corp.redhat.com (Postfix) with ESMTP id BE52A5F7D7; Fri, 24 May 2019 17:35:39 +0000 (UTC) Subject: Re: [PATCH v2] locking/lock_events: Use this_cpu_add() when necessary To: Linus Torvalds , Will Deacon Cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Borislav Petkov , "H. Peter Anvin" , Linux List Kernel Mailing , the arch/x86 maintainers , Davidlohr Bueso , Tim Chen , huang ying References: <20190524165346.26373-1-longman@redhat.com> <20190524171939.GA9120@fuggles.cambridge.arm.com> From: Waiman Long Organization: Red Hat Message-ID: <8ceebb1c-e8f1-8bc5-e032-48f1a653a979@redhat.com> Date: Fri, 24 May 2019 13:35:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Fri, 24 May 2019 17:35:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/24/19 1:27 PM, Linus Torvalds wrote: > On Fri, May 24, 2019 at 10:19 AM Will Deacon wrote: >> Are you sure this works wrt IRQs? For example, if I take an interrupt when >> trying to update the counter, and then the irq handler takes a qspinlock >> which in turn tries to update the counter. Would I lose an update in that >> scenario? > Sounds about right. > > We might decide that the lock event counters are not necessarily > precise, but just rough guide-line statistics ("close enough in > practice") > > But that would imply that it shouldn't be dependent on CONFIG_PREEMPT > at all, and we should always use the double-underscore version, except > without the debug checking. > > Maybe the #ifdef should just be CONFIG_PREEMPT_DEBUG, with a comment > saying "we're not exact, but debugging complains, so if you enable > debugging it will be slower and precise". Because I don't think we > have a "do this unsafely and without any debugging" option. I am not too worry about losing count here and there once in a while because of interrupts, but the possibility of having the count from one CPU to be put into another CPU in a preempt kernel may distort the total count significantly. This is what I want to avoid. > > And the whole "not precise" thing should be documented, of course. Yes, I will update the patch to document that fact that the count may not be precise. Anyway even if we have a 1-2% error, it is not a big deal in term of presenting a global picture of what operations are being done. Cheers, Longman