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 098D9EE4993 for ; Wed, 23 Aug 2023 16:10:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B511280089; Wed, 23 Aug 2023 12:10:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 36504280088; Wed, 23 Aug 2023 12:10:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22C53280089; Wed, 23 Aug 2023 12:10:34 -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 14452280088 for ; Wed, 23 Aug 2023 12:10:34 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 86F9B1C9107 for ; Wed, 23 Aug 2023 16:10:33 +0000 (UTC) X-FDA: 81155857146.22.1E49F9E Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by imf02.hostedemail.com (Postfix) with ESMTP id 794B280017 for ; Wed, 23 Aug 2023 16:10:31 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Oj2bD1BY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.161.41 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692807031; 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=+Z12QXPm+RDkF84iA+wv+FJPe57vLFa9VFZMfDdgrZg=; b=aueuEI2hE8yvcHYuzVAFG3aN1fR/oqLMIPKtmUJaAyEbkOBnc9zrR+3TdE0HswoRESHVWr KpHxApKH4PKScrbCO7WqFmBpQNzASb+++gN1fvyhujbrTdu/NpGjSnBD5fIn48glYi0Lcn rVgxUdEY6zrigcAIzaEnxQZF67vzxcs= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=Oj2bD1BY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.161.41 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692807031; a=rsa-sha256; cv=none; b=RNNiEbuX2VasGlpem+aMtjkk3spCdgCtdoGuxe2hsIHX40KMuAYkHh2YtX7uvqNio1oQTj cQqN0vfrd81ANM+FsbvjmCDqQLTHlx939VPFsMGWOy+Xg+75MXQl29UnMSKGHsoI5Bz6hr oD4DEVQFOGOLpbMU/9gwzQnQ/41B32s= Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-565f2567422so3523153eaf.2 for ; Wed, 23 Aug 2023 09:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692807030; x=1693411830; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+Z12QXPm+RDkF84iA+wv+FJPe57vLFa9VFZMfDdgrZg=; b=Oj2bD1BYQrsDedtb975jwrwTiBtwGojHELCp43NyXpurcwTEyAl3cjHeAtkk3+H9i2 4zc6vx83c/fwBTkk/yBUCtM1BTyehyvCe9WT531ISPzmaCAsaU6YMSOf0Fd5J5nWZNRh +4uNp15MLj5lrzcSAkFMvG0SIfj9+LkOt2xteHQc0nviquFtOiXY7BSTWMPhduCWowuz hn6G5HRhPW3QJYaJED5VbXUaMCszaJz7jlsFHpyEmCG1vBTb9Db5YmEFDg5Pvd+fRk71 WxXq1ihjBkDF9vE8gxW/Z3iLNurl70/yv649QA71xHr/Q1R1wja9PFOJrQz4uxOMzZ3H Y0Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692807030; x=1693411830; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+Z12QXPm+RDkF84iA+wv+FJPe57vLFa9VFZMfDdgrZg=; b=U33fPsOqWgjVDBcN0RzJELXRa7UEDn7/IRovQV6W2IVndQkTokwQ5Uem2noG908heX DkOecDffOUgaYZeVBqVtN6SW8fPNx6ucwaYaC4PllrFRwer3Za7W+H5GXI3FC4jvsq58 95n4vkzHUNndI4Z38aVmvrtEmHCWlJIulCHVtXOESjXCazRpBe6onnS7RimzsrMngulX gzNKksziEFwJU/7BVQWWb8FhYAQrBIYsT1rIvGQAkj2bQMOsjqHjdNjE/YIup7iP7VfJ KdQ7Bth4IfRDo/n6yBOFb+RgqWGwFq5wCcGAvO9/lKXnDWb2DUQBFYzEwXmrn/uNXCKE Gd1Q== X-Gm-Message-State: AOJu0Yy7LaJ8HB3HX3VMUogQ37a6gu0I8Yt+4h5YbcRMrmwyyf0lECdH S58/wdWc6u7b7GFetEaQeMjU8BOmcJxPO6Fdtwc= X-Google-Smtp-Source: AGHT+IGRSsNS00IocQRpXaHBCdTfIY/2jeMXsBQOdIeS808Lmcjm5mO2fEjc+m0Y/BGpPdci2J1A5fcxtMMLCte23Ik= X-Received: by 2002:a4a:2a1e:0:b0:56c:7149:7db6 with SMTP id k30-20020a4a2a1e000000b0056c71497db6mr11355508oof.3.1692807030389; Wed, 23 Aug 2023 09:10:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:5797:0:b0:4f0:1250:dd51 with HTTP; Wed, 23 Aug 2023 09:10:29 -0700 (PDT) In-Reply-To: <20230823154728.rpkw6fpwvwqbnnh3@quack3> References: <20230821202829.2163744-1-mjguzik@gmail.com> <20230821213951.bx3yyqh7omdvpyae@f> <20230822095154.7cr5ofogw552z3jk@quack3> <20230823094915.ggv3spzevgyoov6i@quack3> <20230823154728.rpkw6fpwvwqbnnh3@quack3> From: Mateusz Guzik Date: Wed, 23 Aug 2023 18:10:29 +0200 Message-ID: Subject: Re: [PATCH 0/2] execve scalability issues, part 1 To: Jan Kara Cc: Dennis Zhou , linux-kernel@vger.kernel.org, tj@kernel.org, cl@linux.com, akpm@linux-foundation.org, shakeelb@google.com, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 794B280017 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: qcy1bexdk6er74awgw5t1sbyz1gakkm4 X-HE-Tag: 1692807031-844984 X-HE-Meta: U2FsdGVkX1/uyfWGJmTghsN1Dzl9RiaO6SzLefHeyNGHoIDNquPGPU+Ddbu2+gG73FErwXyGLdwL0XrKo2PLn9/m1EIm5u6H/TkoQvTWO1cJrhsgpZne198QO0IXI2Ssbz34vgZYBuxo8eEbUOVtcf+fDqEG8Y2ZLKIQPc3lAtyfBe7YeBO7XzUi9/lFGWW3UfO4QT0mqzXJQifqYLOeBCOwa4ujCqxN3ql69oWwJhtior1Xu3glNRiT3R4x0VewVAE1XtO9rKm/LkoDlGAT6K74i68hnbsME7DvE+5+CvOopW5NdIo2oX4gumvSchv7NlRPhbGNXFb412Uqe03jTcr2XB8KwQfgHYlCUoaaTnd0lXRExKZh+7uD1E/oE9er39T2cxp29Qsm+jXaEoSvrGB5Uq+lcsVwaGg2BinD8UvK/r7FJnDZ0gEamJNJSMnEmx4biRX4taIdrDTslcF3K/cqKNm5/e5cAugPbHSb/E1rFilZd/GATuhBeqS3WJtYEBfr3auRhnK3fhgmXpXa2R+IMwP0+muMfaoIM/u5tYFtUN6nQSmrQIV0SduVhMiEIRKfkG9UFA86POYpsvom6FkxjuOxR2oO89Q09ehVKQRL1IUEZxN6LEbEZSLKUlgbhjrKzgVPR/7somfdD4cgnE666hqfvABfIBkGQ4iC1jcCmcx/N7isOBVROZJdl11Dx40OCI37zHs58BzP78+jq3xFtN1C+K2aIpPhqiuHXnbYqc3GIIdk9zxurG4dwYO/4k174cSdewwdQA+tKaUU/5/1UDWC3Iups+W2ihzHTsoTEzDTXTfIcUkxd0hXgJG7h5ey8o69PUgFmuKs1PmXrgIeAZAlPsEXv5pOeyKtOZm7RJjpylEd5kE9qgW12pEG1nXBJxGxfVY0QRXd2mnHcpF1vGhreieSmeFWUqO0Ra2y7ufIJ2BNDYwvh4Rqd8eONl5rnFOEA1+yzRdDT0p pzLbrJdf VbM0PmvwcIdwVbjom225rtQRlQCVrxDYMtPq5FIYf+HFTFgPBHT2WmeK1uPgAUItipRRO+M3AnVKohOYLkQQSVnyjcvh6LkdtAk2Bi8/Ls2AzZ2HPhf1mw3+7msBl/P8M1k6wOxMPSdaSYVu1it8X66E3CwbsAuJkcnyC9Zxp+93b3IW2/qfxeLh61XjcJ6rUf6+sVjf6BEPsnM7iEqmmFOZxrPCPqJXm2qUHAl4hcDjGSJabKm3S7hZMzJN5z53XMSp+DL7NgtJihhJ1cDRtMVP5SnufrVDi+upVDH8OE39IRCuWfeffrqGtyabiANNZheMWJnJRpk1zktPapILgSvQP1fxIwpaCZhtV8NsZ2Mgj4ZOT19z6kGRR4g== 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 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); -} 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.... Anyhow, I just found that patch failed to completely remove SPLIT_RSS_COUNTING. I'm going to submit something about that later. -- Mateusz Guzik