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 65EECC3600B for ; Thu, 27 Mar 2025 17:17:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAEAB28010C; Thu, 27 Mar 2025 13:17:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5DBA2800FF; Thu, 27 Mar 2025 13:17:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D73B28010C; Thu, 27 Mar 2025 13:17:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 69C3C2800FF for ; Thu, 27 Mar 2025 13:17:11 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4D09F1CC16C for ; Thu, 27 Mar 2025 17:17:11 +0000 (UTC) X-FDA: 83267986662.15.0334457 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) by imf03.hostedemail.com (Postfix) with ESMTP id 01F8620006 for ; Thu, 27 Mar 2025 17:17:08 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DbjYPUBz; spf=pass (imf03.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743095829; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7bRxmqvl0+EuoCZKk7jNhwWn1DNhdJGHNDr013jHgxA=; b=1/r+nAOSRRdI9OCyoYyRQzvrtymCEkA4awXBFfdsvTC6Mppp5RzTX4Hk67d8pJ+xIy/eJr qyjej47f7HsP8MDQeeFbDQ3YS9dM9fgaCDZdzbqQCD271AGPxHhRx7Gmdh9x0ngvifgZBP joWhbRI9guN3zZ0WOKqPi2HDXLDLYCk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743095829; a=rsa-sha256; cv=none; b=UYx4KSaiCRFN3KtsjMizf0KXfcD3X968TWEH+38OqXiIzBrJ4cyh3M306CE1WC8IqGlFi7 l49sG+fBErE95597BZAoDQpJ000Nd2SMNUryROgHfVqm7eseWPMgy1aoyEQp6OfzxWP0E3 yiiQZ3gATzm5Dz1D19TjzAW2jfm1Wfg= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DbjYPUBz; spf=pass (imf03.hostedemail.com: domain of yosry.ahmed@linux.dev designates 91.218.175.174 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 27 Mar 2025 17:17:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1743095826; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7bRxmqvl0+EuoCZKk7jNhwWn1DNhdJGHNDr013jHgxA=; b=DbjYPUBz42FxzuG4ZqZCVqWnpgGhfPXHNMZS+EKOSShqqcziRC01QRCKJqMEAUA86jYT7c VQYhH2WpnOaSP0rYN4bB8X4OlJbZZgIZz7iUp5CKNAsiIq3wYc1yNJQCrzFCdLEt+QdLgx eVHrqdlkrvzfCWhV0YqlS2BGROUvuDM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Mateusz Guzik Cc: Greg Thelen , Tejun Heo , Johannes Weiner , Michal =?utf-8?Q?Koutn=C3=BD?= , Andrew Morton , Eric Dumazet , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Eric Dumazet Subject: Re: [PATCH] cgroup/rstat: avoid disabling irqs for O(num_cpu) Message-ID: References: <20250319071330.898763-1-gthelen@google.com> <2vznaaotzkgkrfoi2qitiwdjinpl7ozhpz7w6n7577kaa2hpki@okh2mkqqhbkq> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2vznaaotzkgkrfoi2qitiwdjinpl7ozhpz7w6n7577kaa2hpki@okh2mkqqhbkq> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 01F8620006 X-Stat-Signature: 1aznyfhfoy985owz7ehew7fd65qes7pi X-HE-Tag: 1743095828-640323 X-HE-Meta: U2FsdGVkX1/wXhYsR2Di7IA4NXHIAENLs63u2eREWzLKS9PmuEr+PN32AXEXcokXOKz4VcWTMgxX72f7NLguBxiazBAOpfjPcdPioQDVtv2faccGU4vv39dTooKlOYivbvKmgJw2ZE5f4flFlrPqEw831zoVG5tPWFaS+dzMdEvGP0nKeUMJHPOtKHm2ppTApsZyb/mIv5mt+VD0BV2uV4MFf0icelQJydBaMyA2CgxrHAA4iXneuMrud3FoCAnle4ODtL7HqO6CftoNGO/YD7Y4VFweGTLstuHP8+UoDAByWMqzX9fLWBQIQQFfUNzFJx3XtC0Z7Ee8P8t+ilNpL7cGrcPZGcjOWr9eqSARiIkXUliMP5wlTh3yOFf/OjuzUn2rdhyuP1mZoeteD6eLppjY79rr3esQUm3z09dWsK+w/aePip6fMo13+Tp5s3wawHqUdsjOvsiXfDkQPotDsrRzxdCFDCMnOXZI1f0QUeL0GstuXTIAr1jCb7dPEabsgtSAxWO5EZ5ht3kNqDaZAC6mT5J5uB1GqFH2i21BlXMx+p+vvU31luH/i5yYfqEtcss5UagvqReJ9X2vqrUyCuIYGnnA/AQlhMLPbC7BOdTF7yla2mXImpy9ychBhCOPEopkgKwN6eX9EBYgk3iLydHg9ZDakmEb+ZXUuGjMnNSuO4MAABeqiLYUi+wbOUyMdeBebmCs42grDAkqOrfleX5nlLL+Kqzs7L4uBdFMLdMrEFaP5H8OQCTbb6P5nK3iw3PCOAFk1KeyCNKRdYkd/rnJDVxnvyYlE6Kc5v8jC/XyD4QYTd2M+q5PzaXBlpwaryBxdXo/M5seO9BhH2cQr8Tp9NNE0oDHLN6/9Ni/GqpCSTvmBc3TvyVIOwIpoKDAX/Vjw/clknvWI0f7olOs6f0HvThwLcfQkQ9N9UyRxrmC10hM/tvzrQhofjmEi883/eJKV26QZtyhwD+yNAI pvUX1uR+ wE/VKZ/HGStWkJ7/Usf9Phqjp6O4D06vTpLULV5NpbpWr5G/hJOxx5zPetx4H8ucCk6L6zTfz2diVrZJPhq1BYDdAFYIXX3425/WF2tWRCfMcsXUGWjbGtil0NueRqewJgDgGTwaPNO8Hmc8QsbaTphEARwKcDM2JppUubjO8t5uCaZisu26aoSQvCs0u0AnqoD1L3us8xFI5UXYRYb8UwpqSvSzS67xzklijzwPZXoIYqslaA6D7+qPh64l+LqSjafn5Seqy9kg+x68= 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: List-Subscribe: List-Unsubscribe: On Thu, Mar 27, 2025 at 03:38:50PM +0100, Mateusz Guzik wrote: > On Wed, Mar 19, 2025 at 05:18:05PM +0000, Yosry Ahmed wrote: > > On Wed, Mar 19, 2025 at 11:47:32AM +0100, Mateusz Guzik wrote: > > > Is not this going a little too far? > > > > > > the lock + irq trip is quite expensive in its own right and now is > > > going to be paid for each cpu, as in the total time spent executing > > > cgroup_rstat_flush_locked is going to go up. > > > > > > Would your problem go away toggling this every -- say -- 8 cpus? > > > > I was concerned about this too, and about more lock bouncing, but the > > testing suggests that this actually overall improves the latency of > > cgroup_rstat_flush_locked() (at least on tested HW). > > > > So I don't think we need to do something like this unless a regression > > is observed. > > > > To my reading it reduces max time spent with irq disabled, which of > course it does -- after all it toggles it for every CPU. > > Per my other e-mail in the thread the irq + lock trips remain not cheap > at least on Sapphire Rapids. > > In my testing outlined below I see 11% increase in total execution time > with the irq + lock trip for every CPU in a 24-way vm. > > So I stand by instead doing this every n CPUs, call it 8 or whatever. > > How to repro: > > I employed a poor-man's profiler like so: > > bpftrace -e 'kprobe:cgroup_rstat_flush_locked { @start[tid] = nsecs; } kretprobe:cgroup_rstat_flush_locked /@start[tid]/ { print(nsecs - @start[tid]); delete(@start[tid]); } interval:s:60 { exit(); }' > > This patch or not, execution time varies wildly even while the box is idle. > > The above runs for a minute, collecting 23 samples (you may get > "lucky" and get one extra, in that case remove it for comparison). > > A sysctl was added to toggle the new behavior vs old one. Patch at the > end. > > "enabled"(1) means new behavior, "disabled"(0) means the old one. > > Sum of nsecs (results piped to: awk '{ sum += $1 } END { print sum }'): > disabled: 903610 > enabled: 1006833 (+11.4%) IIUC this calculates the amount of elapsed time between start and finish, not necessarily the function's own execution time. Is it possible that the increase in time is due to more interrupts arriving during the function execution (which is what we want), rather than more time being spent on disabling/enabling IRQs?