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 AEF01EE49A0 for ; Wed, 23 Aug 2023 16:41:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37D5728008C; Wed, 23 Aug 2023 12:41:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32D0E28008A; Wed, 23 Aug 2023 12:41:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F52728008C; Wed, 23 Aug 2023 12:41:21 -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 0D3DC28008A for ; Wed, 23 Aug 2023 12:41:21 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E032A1A01F1 for ; Wed, 23 Aug 2023 16:41:20 +0000 (UTC) X-FDA: 81155934720.18.0476B58 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf30.hostedemail.com (Postfix) with ESMTP id A7E9F80014 for ; Wed, 23 Aug 2023 16:41:18 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=L+lhDXJT; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=l6FtSgNt; dmarc=none; spf=pass (imf30.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692808879; 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=BW7dUoeev2xy4pTa2DwHGhHYblYyga+z5up7jx4hMt8=; b=dKgSQ1xvf12DUg8EQ5nu8XhvRaoGIdMa2D6bxVvP91j0GfwZXRnnojiUYFI/YTifLsWxhR HZQvKv+z/hnvij7X+XsMRwmLNAa53srLXy4vJMxFINzECtZvDaiC6f9wpYo4M8pwoSHg36 hm7pMOXOFAkUdXxG37iNMuncSWFSH6E= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=L+lhDXJT; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=l6FtSgNt; dmarc=none; spf=pass (imf30.hostedemail.com: domain of jack@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692808879; a=rsa-sha256; cv=none; b=0+8YBsE4LrTUZaC82q3VpodLNGAjHuZvSY4KxsEmv7f/mMfwrbL53y9jcY+ZPrYkDb109/ qhFakNyGNayfgJNN1k30wbOYUecyO3IpieQ5tJLoBZ0Vmsze70pB5BOW1rh8KD6TljFbnR U/J3D14z5gl4eaZnt/Q7T6vdUmTG4kc= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id C0E182095B; Wed, 23 Aug 2023 16:41:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1692808876; h=from:from:reply-to: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=BW7dUoeev2xy4pTa2DwHGhHYblYyga+z5up7jx4hMt8=; b=L+lhDXJTTwCjMnG1V3E8gPKdXlku9RCyowfjssYcX58/OxnSEaxu35BVxRT4wl82O7Cy2N D9zVsbT0YDJtFQpHjSvDDoKf9kSHDDVCjbNv3og9plp+CPG5WbkGAsTpB1NlKPhnwURq3F vuxdo5Lr/RESWXMBFjVLO0lyxZvLIVs= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1692808876; h=from:from:reply-to: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=BW7dUoeev2xy4pTa2DwHGhHYblYyga+z5up7jx4hMt8=; b=l6FtSgNtSu23pB9LUXqChxXGNFyWm31qFn1Mh8QUjcegmIHdODp/WnFX/kLzYrGhlTSbJY bIBl/ak1MpkljpDw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id AC0661351F; Wed, 23 Aug 2023 16:41:16 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id t5z4Kaw25mRwSgAAMHmgww (envelope-from ); Wed, 23 Aug 2023 16:41:16 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 24FE3A0774; Wed, 23 Aug 2023 18:41:16 +0200 (CEST) Date: Wed, 23 Aug 2023 18:41:16 +0200 From: Jan Kara To: Mateusz Guzik Cc: Jan Kara , Dennis Zhou , linux-kernel@vger.kernel.org, tj@kernel.org, cl@linux.com, akpm@linux-foundation.org, shakeelb@google.com, linux-mm@kvack.org Subject: Re: [PATCH 0/2] execve scalability issues, part 1 Message-ID: <20230823164116.aqjl6f5m2o3rwyxe@quack3> References: <20230821202829.2163744-1-mjguzik@gmail.com> <20230821213951.bx3yyqh7omdvpyae@f> <20230822095154.7cr5ofogw552z3jk@quack3> <20230823094915.ggv3spzevgyoov6i@quack3> <20230823154728.rpkw6fpwvwqbnnh3@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: A7E9F80014 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 1eic9xspaxxkcrxjc3k1m4h9fjg7zcco X-HE-Tag: 1692808878-131169 X-HE-Meta: U2FsdGVkX1+hTPCu2bD1xz+9Zs8MLRMegFfqaYDoc9Hb0alOa225zmfrtLkt2d2iKGAW5GTcSB6kypeazrIiH3sfHpYPk3ci+W3UWtexE/4ewjokbXPsdiXj5xXkacHIVJCT+m2V87ATzJhEgr9Ck3xkt+ruh+ZGzLszzPE4XC01ngru9c6aRqLCsN74sGmQof07TMgRQUQifP28IE9ImYUwX0yURJhXNc/qQD2lHqonKl5AHCE+7PDEscna35CgO3pW7gmBapfUgXPP1IkhnRvSnDQ/mmy+bjBlh0zLd+7sPQ1HKFrZaEyHC3+KUh2VTDBF/a6Y/4l10w1JP+kI2pog+wkEJe8EzjMPecyEri6v089PHBASioxYJ8aq/BeOJkkvI9OD8jzTkzL6ZmG9/XLtGwSvyRmHiPDM+YN4oVdL5e/r2E1bomJN04e+AH/ahabnUEAtNl2smha4K3dxAdDPfZWEAgm1BU/IgHBU2p813ORzyjzQEc7wPMEEqlMdApxIzUTFTRrmiUh8wJk8kldS04+Dm86LIiv5Beg5MqyakLXG9MH8HOjPRuLpfS8B4tVJ34dttgwxq+Te08DlMl7GvC6Dtwad/7RmHmKV25SSF4vpBHJmMxrtoTOGtwgS8JKyQdfKf7pB1Si3xGc6rC1xmM28KSPv/lgomcwBSdDVCCGvsmKUqsXy08SJ8nGfJ66ydKY2Wq7Mi/CMsW4gQhwczdGZEPeRaZvMv8+qgNo7YFIn+aOSPJW2sR8DJw89lfYoFKj/lhOpvWFeeDaxYtyiEUOqFuP8DCx2O9XFBhcKvBUQmeOfs1uqlDIJyUoNZnuzN+evhc7iJI9W9YlkRAi6xQQpmx0HklQNiOOgs2p3+Wqs2Q9j8RDH5ozHZtpEFcc3tflTlE17ORc18bWKLaCPAFYZKBjDYPFis8PB2gbrsD5sZJzgCkoSFKiaJPzj4rHNdwJQELap6jfvsNq GNlFG0Hs 5Ffvl5CNdBQLcMbVGo9tykeWJa16wnROfxtPnssyNhT18p3KlTmRGOykwwdhLZ1L5k2p0uUb14awXPB7V15dE5kPjOxEbiU7DE6XdzvFQpgjLCqCbbWDM+Cs35oHSy8o9i4ZWXBPJL16XnBk5fS8fcnBF66Ng+gZZsnKICvljMAkiyeQOR8p2GrXLRQ4PVoVKL9VaRrG4X4da5tZ4jYIGLtv5Qj+1AXigWNS7HZvfKavhxiNnmKiEBusE9g== 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 23-08-23 18:10:29, Mateusz Guzik wrote: > On 8/23/23, Jan Kara wrote: > > I didn't express myself well. Sure atomics are expensive compared to plain > > arithmetic operations. But I wanted to say - we had atomics for RSS > > counters before commit f1a7941243 ("mm: convert mm's rss stats into > > percpu_counter") and people seemed happy with it until there were many CPUs > > contending on the updates. So maybe RSS counters aren't used heavily enough > > for the difference to practically matter? Probably operation like faulting > > in (or unmapping) tmpfs file has the highest chance of showing the cost of > > rss accounting compared to the cost of the remainder of the operation... > > > > These stats used to be decentralized by storing them in task_struct, > the commit complains about values deviating too much. > > The value would get synced every 64 uses, from the diff: > -/* sync counter once per 64 page faults */ > -#define TASK_RSS_EVENTS_THRESH (64) > -static void check_sync_rss_stat(struct task_struct *task) > -{ > - if (unlikely(task != current)) > - return; > - if (unlikely(task->rss_stat.events++ > TASK_RSS_EVENTS_THRESH)) > - sync_mm_rss(task->mm); > -} > > other than that it was a non-atomic update in struct thread. > > -static void add_mm_counter_fast(struct mm_struct *mm, int member, int val) > -{ > - struct task_struct *task = current; > - > - if (likely(task->mm == mm)) > - task->rss_stat.count[member] += val; > - else > - add_mm_counter(mm, member, val); > -} Ah, I see. I already forgot these details since I was checking the regression back in spring. Now I've just seen the atomic_long_t counters in task_struct and forgot there used to be also these per-thread ones. Thanks for refreshing my memory! > So the question is how much does this matter. My personal approach is > that avoidable slowdowns (like atomics here) only facilitate further > avoidable slowdowns as people can claim there is a minuscule change in > % to baseline. But if the baseline is already slow.... I get your point but over the years I've also learned that premature optimization isn't good either as we will be dragging the maintenance burden for a long time ;) It's a balance. Honza -- Jan Kara SUSE Labs, CR