Received: by 2002:a05:6358:489b:b0:bb:da1:e618 with SMTP id x27csp1893790rwn; Fri, 9 Sep 2022 05:50:31 -0700 (PDT) X-Google-Smtp-Source: AA6agR7ALLXO1v4PkDxuz8yqT1n5kyUCwI3e3FtLKMKSYZojYWFWKGrV1prpJRZGni97CKnd4NtG X-Received: by 2002:a2e:b6d3:0:b0:26b:ddd7:919 with SMTP id m19-20020a2eb6d3000000b0026bddd70919mr1739253ljo.491.1662727831518; Fri, 09 Sep 2022 05:50:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662727831; cv=none; d=google.com; s=arc-20160816; b=j8pc6eWWJuyOz6cyb6sVlGCdqpS1Qc3ntf3gQeCEzBSQFKFXj5xNbz967HrUKz31pK j/241DZTgfGJKRUgvBNjdPDwbSbletbpgOwjuXgkQZObmL936Aa9iTh5AOKud4656oHw GPA6OEIWZnmmZt6uxdctb+GO69V7hhCWjfT0Ic43f3f7LkIqe1+Tcl1H/Itj/LD/cbj8 XjoSf+U0Dzh3O7b0J3qlg/x645s91M0TBSEunPZdabdWR6LtMZgOwpeDwRZibF6iqXE1 KQERS/98irzueXZkhg53XJT88h9hX2p3KJbXM8APiANP6AlYxqwIAxHIPeTePRkvGaIX nCrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=UAAQ+YLzvmmUI6dBHAsDTOGyqlQLeOvNNzTP+cKD4uk=; b=nSv2hTPKFciPrkapJoCRrXVHkhc2eMg0L31r3vJoV9a7+pt8Fn8hfWJE6Gj5MVMll9 Hegt8jGPGczpQ6SAaQpV5eBsySg9l057xz+AM5sZDu1zKejGfLCuycp3OHQI4UUA039S +CWylThBdQi/O34BEwueOeS9JtktiBPIFnf5rHoxb+Lyzj5dGrKObJLryNSc5eFNFLQr YFvmM/IbIgvCrewwtl785KM+yIyNM6wVG2XTvI66W95iQ0NCebNHRr5Vm2hvaGzNH/z4 BRpirMLkzynK5wgQ9qSdZHERNKz9xlpmtg0stxYtp/QcnHtj3z+2n2R+tbL5TzG2jdPU bDuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RRVm+v3M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bk39-20020a05651c23a700b0026acbb40daasi235230ljb.620.2022.09.09.05.50.00; Fri, 09 Sep 2022 05:50:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=RRVm+v3M; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231446AbiIIMUC (ORCPT + 99 others); Fri, 9 Sep 2022 08:20:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231421AbiIIMTf (ORCPT ); Fri, 9 Sep 2022 08:19:35 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5264F11452 for ; Fri, 9 Sep 2022 05:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662725852; x=1694261852; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=UAAQ+YLzvmmUI6dBHAsDTOGyqlQLeOvNNzTP+cKD4uk=; b=RRVm+v3ML6ZI55FuhTAZaubBujoKuP2qAvoJov8ypCW0EtTB/jbT0c70 CRyd/YKCEYKJUkWs9yWAkwfG9qcgZX5ogvsn9Jngzc9iPih8v7OSMYkYe GWJd8c8HekVb5Wc2EpjPaK5NTWUard5WOxk/2mTH/FTecu152uANGVIrX X5cpBtqs1Hv4gpn4jQHEqgMvuPztdULFNehgWaXiC+7Cv2tXoiPmjZ9VG OpjCphR6GQM9d6x5lgNkUQWu5c/+YuzOFlGd0BfcV96oO6lYfoqZMH23K EgjcL9zMXXgS0k5gCYt6vtMegP2hZMnMcYXbuAw7jWbQUh0VzGVzkrmYg A==; X-IronPort-AV: E=McAfee;i="6500,9779,10464"; a="361416745" X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="361416745" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Sep 2022 05:17:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,303,1654585200"; d="scan'208";a="645516055" Received: from linux-pnp-server-13.sh.intel.com ([10.239.176.176]) by orsmga008.jf.intel.com with ESMTP; 09 Sep 2022 05:17:28 -0700 From: Jiebin Sun To: 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, manfred@colorfullife.com, 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, jiebin.sun@intel.com Subject: [PATCH v5 0/2] ipc/msg: mitigate the lock contention in ipc/msg Date: Sat, 10 Sep 2022 04:36:34 +0800 Message-Id: <20220909203636.2652466-1-jiebin.sun@intel.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20220902152243.479592-1-jiebin.sun@intel.com> References: <20220902152243.479592-1-jiebin.sun@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_06_12, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Here are two patches to mitigate the lock contention in ipc/msg. The 1st patch is to add the new interface percpu_counter_add_local and percpu_counter_sub_local. The batch size in percpu_counter_add_batch should be very large in heavy writing and rare reading case. Add the "_local" version, and mostly it will do local adding, reduce the global updating and mitigate lock contention in writing. The 2nd patch is to use percpu_counter instead of atomic update in ipc/msg. 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. Changes in v5: 1. Use INT_MAX as the large batch size in percpu_counter_local_add and percpu_counter_sub_local. 2. Use the latest kernel 6.0-rc4 as the baseline for performance test. 3. Move the percpu_counter_local_add and percpu_counter_sub_local from percpu_counter.c to percpu_counter.h. Changes in v3: 1. Add comment and change log for the new function percpu_counter_add_local. Who should use it and who shouldn't. Changes in v2: 1. Separate the original patch into two patches. 2. Add error handling for percpu_counter_init. The performance gain increases as the threads of workload become larger. Performance 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) Regards Jiebin