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 28A16ECAAD8 for ; Tue, 20 Sep 2022 04:53:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FC2A940008; Tue, 20 Sep 2022 00:53:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 283FE940007; Tue, 20 Sep 2022 00:53:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FE3F940008; Tue, 20 Sep 2022 00:53:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EE1F0940007 for ; Tue, 20 Sep 2022 00:53:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B750D1A0518 for ; Tue, 20 Sep 2022 04:53:50 +0000 (UTC) X-FDA: 79931246220.28.270FD32 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf07.hostedemail.com (Postfix) with ESMTP id 536E44001B for ; Tue, 20 Sep 2022 04:53:50 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id t14so2305946wrx.8 for ; Mon, 19 Sep 2022 21:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorfullife-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=Vyg2BS4OgoN4PABi0kgWr5r2OkJO3xdUk2Gib7RnQ68=; b=pV5NEnzzTDNCMhIzv9W9eopezRmZC6OUF2OXuGZ9QRaxsXFUqT/5cgWD4AGCTFPCTe TZim8aD+ldgXRmWVldy/lzKLR+IMaFm+0C190mV2ozj8V6y+ZSJSHpJ7IqXJJmosUFCe 4s8uLn1Bdg6rHPn6jCHn4OCyydLcbXzMGG8Z95MxVdlW+HPfIuqdrxfT+ZZ1c4VomHc5 NEuDuICS60ulIQzhJeDcTXqLVO3ycKcpMSZy7bsh4eRkUTJFGdMQaEhG5WhycshOQivE nnUAE2gwIcb396TpI3cZHfZJWe9Ly9qgiXY2cVxwIZvbIlM88m9tp5qVxNmE0YewNwmX 8rLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=Vyg2BS4OgoN4PABi0kgWr5r2OkJO3xdUk2Gib7RnQ68=; b=F68ZOwgCz2b83RD9rHY8wdqCDQPR35qcUot4ymVI0BtKZ99gtpnaTqxhamaQ7bzEnV ZReHJ7T+bxzrtgHCltleOLYUSFuYeXQT3N5268L9k9myh8yjxRfojX5mW8DPqIeVlcgJ JyBs3wBuWknr+xN0kKqBrYfSm0cMjCr1D+B9lawElJ5PsErjHWeCkEbknZ+MVtL0N4iK 6+J7s1LxVSUnOPitFsoU8B9AGWjsPgR9pI4CJ/9VQMy1mn+dIZGsO7M+Bd1Rimb8EV8C sx0l8fJqQzA+FacrpBu7y+Jy4Bejtj9NWv6rcN3Qmhf8IBh4T2vluHKl722Bm6qfuE+L kt+g== X-Gm-Message-State: ACrzQf1DHVzNnhQjekAcXThcCKQN1ugVEftELSCAJrNtrtnlp3FxHDsS OHpptMCIffjtQqAz1wd6z4l+og== X-Google-Smtp-Source: AMsMyM5T6ErMvRyjiulCy6Ti1NqzRjFy2W7YBOLNH2YjQZqju8DY9WfnCm2AB5oJUKaKhAVsKpJbhw== X-Received: by 2002:adf:d08d:0:b0:22a:4560:9c29 with SMTP id y13-20020adfd08d000000b0022a45609c29mr12541726wrh.579.1663649628800; Mon, 19 Sep 2022 21:53:48 -0700 (PDT) Received: from ?IPV6:2003:d9:970b:c00:6690:5cde:f1af:9517? (p200300d9970b0c0066905cdef1af9517.dip0.t-ipconnect.de. [2003:d9:970b:c00:6690:5cde:f1af:9517]) by smtp.googlemail.com with ESMTPSA id r13-20020adfa14d000000b0022af5e36981sm522866wrr.9.2022.09.19.21.53.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Sep 2022 21:53:48 -0700 (PDT) Message-ID: <8d74a7d4-b80f-2a0f-ee95-243bdbd51ccd@colorfullife.com> Date: Tue, 20 Sep 2022 06:53:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH v6 2/2] ipc/msg: mitigate the lock contention with percpu counter To: "Sun, Jiebin" , akpm@linux-foundation.org, vasily.averin@linux.dev, shakeelb@google.com, dennis@kernel.org, tj@kernel.org, cl@linux.com, ebiederm@xmission.com, legion@kernel.org, alexander.mikhalitsyn@virtuozzo.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: tim.c.chen@intel.com, feng.tang@intel.com, ying.huang@intel.com, tianyou.li@intel.com, wangyang.guo@intel.com, Tim Chen References: <20220902152243.479592-1-jiebin.sun@intel.com> <20220913192538.3023708-1-jiebin.sun@intel.com> <20220913192538.3023708-3-jiebin.sun@intel.com> <6ed22478-0c89-92ea-a346-0349be2dd99c@intel.com> Content-Language: en-US From: Manfred Spraul In-Reply-To: <6ed22478-0c89-92ea-a346-0349be2dd99c@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663649630; a=rsa-sha256; cv=none; b=uVoOEiDiMOXnh+bx1ecY9vavF9ujQnqEfy+wq+gjcYHZ9hA1naBVmIeJSDTYaEWD9/PfV4 krxkrfmQlV66jPy7tQ+LetL1AERtyUQ5+BMY8c6e+jGwhXitCJrLS1sWMuXAInKw53TEfT 8saJR+n9+1Gw8JbHWB9UpgzQkMIJAjg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=colorfullife-com.20210112.gappssmtp.com header.s=20210112 header.b=pV5NEnzz; spf=pass (imf07.hostedemail.com: domain of manfred@colorfullife.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=manfred@colorfullife.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663649630; 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=Vyg2BS4OgoN4PABi0kgWr5r2OkJO3xdUk2Gib7RnQ68=; b=3xDfjH5TXsn0xn2FQcGHe2ompo8883hq0FF9Pa/a48JJ2HYG8GlZvZvJLXwhYX7GZbZ3ig m4V4aFISYhbIIU4x+W+QWs8jyv3etPWqYrCjMLapw9d2DSkyv0nrbW+ESndf3dT0h6mCZ6 HrEzSalZxPZ7UC+x/M9VNTyqT04JDqc= X-Rspamd-Server: rspam06 X-Rspam-User: X-Stat-Signature: mdqer3eytydjcfjpgjyhka6ykrcn3a3k X-Rspamd-Queue-Id: 536E44001B Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=colorfullife-com.20210112.gappssmtp.com header.s=20210112 header.b=pV5NEnzz; spf=pass (imf07.hostedemail.com: domain of manfred@colorfullife.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=manfred@colorfullife.com; dmarc=none X-HE-Tag: 1663649630-241967 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 9/20/22 04:36, Sun, Jiebin wrote: > > On 9/18/2022 8:53 PM, Manfred Spraul wrote: >> Hi Jiebin, >> >> On 9/13/22 21:25, Jiebin Sun wrote: >>> The msg_bytes and msg_hdrs atomic counters are frequently >>> updated when IPC msg queue is in heavy use, causing heavy >>> cache bounce and overhead. Change them to percpu_counter >>> greatly improve the performance. Since there is one percpu >>> struct per namespace, additional memory cost is minimal. >>> Reading of the count done in msgctl call, which is infrequent. >>> So the need to sum up the counts in each CPU is infrequent. >>> >>> Apply the patch and test the pts/stress-ng-1.4.0 >>> -- system v message passing (160 threads). >>> >>> Score gain: 3.99x >>> >>> CPU: ICX 8380 x 2 sockets >>> Core number: 40 x 2 physical cores >>> Benchmark: pts/stress-ng-1.4.0 >>> -- system v message passing (160 threads) >>> >>> Signed-off-by: Jiebin Sun >>> Reviewed-by: Tim Chen >> Reviewed-by: Manfred Spraul >>> @@ -495,17 +496,18 @@ static int msgctl_info(struct ipc_namespace >>> *ns, int msqid, >>>       msginfo->msgssz = MSGSSZ; >>>       msginfo->msgseg = MSGSEG; >>>       down_read(&msg_ids(ns).rwsem); >>> -    if (cmd == MSG_INFO) { >>> +    if (cmd == MSG_INFO) >>>           msginfo->msgpool = msg_ids(ns).in_use; >>> -        msginfo->msgmap = atomic_read(&ns->msg_hdrs); >>> -        msginfo->msgtql = atomic_read(&ns->msg_bytes); >>> +    max_idx = ipc_get_maxidx(&msg_ids(ns)); >>> +    up_read(&msg_ids(ns).rwsem); >>> +    if (cmd == MSG_INFO) { >>> +        msginfo->msgmap = percpu_counter_sum(&ns->percpu_msg_hdrs); >>> +        msginfo->msgtql = percpu_counter_sum(&ns->percpu_msg_bytes); >> >> Not caused by your change, it just now becomes obvious: >> >> msginfo->msgmap and ->msgtql are type int, i.e. signed 32-bit, and >> the actual counters are 64-bit. >> This can overflow - and I think the code should handle this. Just >> clamp the values to INT_MAX. >> > Hi Manfred, > > Thanks for your advice. But I'm not sure if we could fix the overflow > issue in ipc/msg totally by > > clamp(val, low, INT_MAX). If the value is over s32, we might avoid the > reversal sign, but still could > > not get the accurate value. I think just clamping it to INT_MAX is the best approach. Reporting negative values is worse than clamping. If (and only if) there are real users that need to know the total amount of memory allocated for messages queues in one namespace, then we could add a MSG_INFO64 with long values. But I would not add that right now, I do not see a real use case where the value would be needed. Any other opinions? --     Manfred