From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3633C54EE9 for ; Wed, 7 Sep 2022 22:10:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 573588D0002; Wed, 7 Sep 2022 18:10:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 524456B0073; Wed, 7 Sep 2022 18:10:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EA2F8D0002; Wed, 7 Sep 2022 18:10:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3095E6B0072 for ; Wed, 7 Sep 2022 18:10:15 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0EF05417E4 for ; Wed, 7 Sep 2022 22:10:15 +0000 (UTC) X-FDA: 79886683590.12.FAA6EDD Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf24.hostedemail.com (Postfix) with ESMTP id D8ADB18009F for ; Wed, 7 Sep 2022 22:10:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662588613; x=1694124613; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=+WGzlmVGQfVQKwWsQ/nLccXRYPuiLkLOyjP7dhlNJe8=; b=j0kvVZJCbP/IXIQM4mYHLowGXIPYXVVrifzblQdmRmuDKwrfZoeLYHzY tJQaoQof5ezIhUoHNxiTXNhxFyLNb3bjA2jPBM4voHPw6ea7CztFLZLjg 4Pc1CevcbF/9tIvwLh0YCTpRND3MF2yo9Gd8XqWX5CCmRWwyuEbPVpk+w O5nmXQ0zrvkO0mmNZifFV1kQMpQkRmMqplgaeanZxUhEG4CDpu71twEBA 3GsOzuX5aq1JbDIq36+zEQU7HywTwTn4gtdcKDZ8G2+myUPvu1hMHsPiD ik75dj5FzpZReirVwXM6OjVjD1DhFE9gpfs4lvU+Vsm0CWEv3IC/K9+j0 Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10463"; a="276746356" X-IronPort-AV: E=Sophos;i="5.93,298,1654585200"; d="scan'208";a="276746356" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2022 15:10:12 -0700 X-IronPort-AV: E=Sophos;i="5.93,298,1654585200"; d="scan'208";a="644804153" Received: from schen9-mobl.amr.corp.intel.com ([10.209.53.232]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Sep 2022 15:10:11 -0700 Message-ID: Subject: Re: [PATCH v4] ipc/msg: mitigate the lock contention with percpu counter From: Tim Chen To: Andrew Morton Cc: Jiebin Sun , vasily.averin@linux.dev, shakeelb@google.com, dennis@kernel.org, tj@kernel.org, cl@linux.com, ebiederm@xmission.com, legion@kernel.org, manfred@colorfullife.com, alexander.mikhalitsyn@virtuozzo.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tim.c.chen@intel.com, feng.tang@intel.com, ying.huang@intel.com, tianyou.li@intel.com, wangyang.guo@intel.com Date: Wed, 07 Sep 2022 15:10:11 -0700 In-Reply-To: <20220907143427.0ce54bbf096943ffca197fee@linux-foundation.org> References: <20220907172516.1210842-1-jiebin.sun@intel.com> <20220907143427.0ce54bbf096943ffca197fee@linux-foundation.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662588614; a=rsa-sha256; cv=none; b=ZwPuR57yDfvugONB1wtI49Gg9AyL+Dd1ntRhePVbFWU355oKSgu3rPQLReglK2fb8rP9+A KfJ/gO4mRzyLC5X4Zr+Oug/bRoKeqTGvBPQ/W1q/UGquUTImjPYh1yXpCH9d/+sorDoeaY NyqOfF+KWgjADa2InDHaBdMwsw3d9pM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=j0kvVZJC; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf24.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=tim.c.chen@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662588614; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kHT3sj67C6kT6LyuL/IQLLnOkQW/3bhKZ4KTx7M39R0=; b=eQjcO9hNRTCEsOcupxH4whMaqlRDdWih36cjc6M64hJBTRmGM5ZgqQJgk7OKG3BkObOfAq zAeDtWmawQmuMS4oT88azGsjm0oPbrQbilnKgZKLT+xdjeLll7IeVyA9tYlAAIxQfiY9B3 90HyxBnhv+shosig20Up3/WPNB4rvkY= X-Rspamd-Queue-Id: D8ADB18009F Authentication-Results: imf24.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=j0kvVZJC; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none); spf=none (imf24.hostedemail.com: domain of tim.c.chen@linux.intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=tim.c.chen@linux.intel.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: a9i8ts9gu1ccpngjkm7tsrmr4bn9ji89 X-HE-Tag: 1662588613-719670 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 2022-09-07 at 14:34 -0700, Andrew Morton wrote: > > I think this concept of a percpu_counter_add() which is massively > biased to the write side and with very rare reading is a legitimate > use-case. Perhaps it should become an addition to the formal interface. > Something like > > /* > * comment goes here > */ > static inline void percpu_counter_add_local(struct percpu_counter *fbc, > s64 amount) > { > percpu_counter_add_batch(fbc, amount, INT_MAX); > } > > and percpu_counter_sub_local(), I guess. > > The only instance I can see is > block/blk-cgroup-rwstat.h:blkg_rwstat_add() which is using INT_MAX/2 > because it always uses percpu_counter_sum_positive() on the read side. > > But that makes two! Sure. We can create this function and use it for both cases. No objections. Tim