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 4DD9CC282C5 for ; Mon, 3 Mar 2025 04:59:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C08BF280003; Sun, 2 Mar 2025 23:59:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB900280002; Sun, 2 Mar 2025 23:59:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8045280003; Sun, 2 Mar 2025 23:59:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8B748280002 for ; Sun, 2 Mar 2025 23:59:16 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2A2CE80C5D for ; Mon, 3 Mar 2025 04:59:16 +0000 (UTC) X-FDA: 83179035912.26.91A5013 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf15.hostedemail.com (Postfix) with ESMTP id 36EA7A0007 for ; Mon, 3 Mar 2025 04:59:13 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OMiS3J3j; spf=pass (imf15.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740977954; 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=2AKL8SKZu8qxAIA6zFPIrXql+KhkgwJaSFEh+bZIrR8=; b=uUytco+yUFz2wL3XWgK5FgV7EeTHC848WMKI5q2ADXtAvbVbVScdyhOgjN0rgK6oZxAWwn vAW+SdRQqdWohbrGfLuUksrJ1cRLO3gyq4jKmfWqA1my1xUkwWHNafeDepDvdSjw0l4AV3 71wDvPiN0OWJA68dH0hA0ScfCLLG6Go= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=OMiS3J3j; spf=pass (imf15.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=ryncsn@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740977954; a=rsa-sha256; cv=none; b=r1ZfLz7qbTwKabHAkHM/vs0ApFwhA2mX2aax+uQyitLyJ95s+g98Qwyxhfpp5aV7cduxZl 7Z+iG500xJFTXf0v/VfOg6Y8Er6w5RIyWO1gM4lL5w7Tyv2+FEoPSU0UwENK1mcg7ThtB2 0Ig72Qru0YdvlusNL6lyy/zeWCT1tFs= Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-307c13298eeso48030791fa.0 for ; Sun, 02 Mar 2025 20:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740977952; x=1741582752; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2AKL8SKZu8qxAIA6zFPIrXql+KhkgwJaSFEh+bZIrR8=; b=OMiS3J3jTgFEyKDnRmHh6yeAm0dLjzAt1CpC8r02gU+b9kfPlBrPXaW3huakrLFV8H wYshf+Gj/yF8bs09tk1154NvKrd56nrAXQozvMtlAbLbVQ55dO7xfAr3Gn/9kFCkHidG oR1fbq2qf7FcHmlL37b2ccaWfGAoIAwr2EOznhqeLJLnxznJP488YR5xSLk3Jl9CVyMf yYXWGDXeKlXJtdcuH3bo3f2BNCrLULB5mP9b6ZzZ0dRcXPf4RqYHNFw8VBiIwjb3VScd kO6wFJHllL7rTKuwEuClrNJuJG9hm09plIIHZBz/0dSoAY8lKfse3LosvWYCGJ0FFEKF Hheg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740977952; x=1741582752; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2AKL8SKZu8qxAIA6zFPIrXql+KhkgwJaSFEh+bZIrR8=; b=j/h1woYImx5GXoJmS26zQn2oWdVMRVrP4dq6EVoeDB2/mArH7qomsYLKwdGFR3ukeZ TwmcBwCqbIxZd27/KC8mkwSgDC5GsO1VDeVnXlFeWFaNPTx0oiCuFo8JDvmYS2UpX5Tg L1pwwIXpnufSEZik5SVlZzAFEngrir58AfiJUJ6iymrbkPJRrf3rxhUsCOpGHp2lw5Dj I0lecO9b5uuIr5QdDYcpEm6KLiuXYIZgSuUHRJVndllijw7SutIWrOCn9Q/RtvQ2giTu 52gCuOL5PeFeArnEWmdH/wlY5Ni1zgQwvAqoUseQkUbflwN2FKWAN8NN52KztbEIx4Xu HQjw== X-Gm-Message-State: AOJu0Yyfhztv2bmqey1vGbY4EJJcL8AZBKAaoJNg4QbJ0KSLHFYhI0P8 FmalvHTPqI3gBnroBOm2TpiStKTPHRsDUbVTwoqV7d25zlyxE8h4GpIOzDB83G6I2p8iXDrjeEe JkV+8f9HV+xO7ftxucSyXC/dlP9o= X-Gm-Gg: ASbGncv2nwPGh3h/zmLbOhoi98FAwQR5vY92rbcTkdvPS9jNjSTnkhlVuh6ztsJl0iF U/ZYtKmnnHsOFg8QoCkGJRe4lS7/J1pE40Qvr1elbXJDQ8shGl2/c/HON7237fj4dHt7eOO6Yv5 dXhxNE5U+HM18azfRoyx21J8Fk X-Google-Smtp-Source: AGHT+IEAtFFcetcY7zoF2qAWQUb80Tls38NY6EetSVN75eHGUPbMNTdwAm6sPHw0hd2wr4vX9DyO1MCNT2ph9KwjFLE= X-Received: by 2002:a05:651c:10a9:b0:30b:94b3:7f87 with SMTP id 38308e7fff4ca-30b94b38053mr32875801fa.11.1740977952000; Sun, 02 Mar 2025 20:59:12 -0800 (PST) MIME-Version: 1.0 References: <20250228113836.136318-1-jingxiangzeng.cas@gmail.com> In-Reply-To: From: Kairui Song Date: Mon, 3 Mar 2025 12:58:55 +0800 X-Gm-Features: AQ5f1Jqo4QE_ivXS8zESh5ah9iVl4djrg-xm0XcJL5U3-QNM525ryL7hsBeZSEk Message-ID: Subject: Re: [PATCH] mm/list_lru: allocate on first insert instead of allocation To: Vlastimil Babka , hannes@cmpxchg.org, Jingxiang Zeng Cc: linux-mm@kvack.org, akpm@linux-foundation.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, david@redhat.com, muchun.song@linux.dev, chengming.zhou@linux.dev, lkp@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 36EA7A0007 X-Stat-Signature: cd4tobuzt3j7mrkp1iio4juuzb4h6u8j X-HE-Tag: 1740977953-486606 X-HE-Meta: U2FsdGVkX1/7xthtgZ6tKEya6kpGbGerOm+m4oTLuhFkm8af7K0fSv21KkwcjWAeW1dfxr4aHnvUqXGj0xCHOX83lCqVYBKYtWWBabX5klbUMKfI53QJAdglWcC4wXiKEWPoH0dqi5yStwWoRYuvNO36MU6CJZsSe/UleJqdXkw/TTEQF58axm4tKiaM1q9AYyJZrItAqo356b283TdVufaMHx41TulTg0fuW8KKs+5Q9yb1Ji84JRc6t/haa+ryYTNK1Sm8sxf9brpqt1PI5DtXQlUcDcohTN07iiR6/t68WBqYZPFhDuf4aBhYnasgodbt3ePBg7h0EAHz07WdpuNLYdHoe7IFl4AuDLx0OHT0yQ94rvrl5JmsL1NuTDMYCZNw8VvyU7BQWnSZN0MunP8vbPfizXwao/414FHwVg7XfiKjGPTmI83d6JLrpG5Vzlv6V7iEhcLsblqh/LE/rSajucshu5Yz3eLv/zBZpOyiHJlVwxmpQYM1EbamgGWsBB3L/sE/IsTMHZdMETFK7rwPOst/irkxlw25x1RG1kZOkaUJrjzDi1Fy2BsBvvkIJ2Tuv1ekayo9mIAa+nSX08izlU1JdMHDWPncKu1sO4rlHvm2d7Wgu9a/SfpzC+ahsF/z8msY8EuTY02lE2bh9QkO2Ec1j7qzNnpjOfcYidABsQsdrX5jzGry6vY6/nIGfid37S1GjLvwCTNAO8dk+pA33YdvqkrgQF4tPOz4fDJIPSL4tkriaMGNBjy54/V9xbj+UWb2oryUZznwlWsVMbrv7Pf8PxIwLUO4ExUFlbHkC3OMDvvhuYU1KlU3AKOKWhkihRLlS4lBnL4grccLttAyhYOp0SZt2pTdwLn+LoX1PCMxCp3B5JFQ/Lip/EG+XZt2eAAn5U/rjk/Vjr2rURj9r8UTLx+lxsYuBaXw70eRfLPbey4EfX9hgTn4Rqs6x19HxWWicPeAoKiUeSM K+1ZZtxg mr4uKpEvMO21iKVIEA6yXoKFa9syfmWZegLndVFvM27vKNh16gkGOlzLYR7e32rE23g8RIfldIuov7oLwQKTJSHHY2QkcV7aXkEiNOrhlHaJD4JTUg/gYgejkHd0FQc2P+6gwE2eK8RGVKddLy0ioHYXDCiQc4Ch4mPr6L8DB71d6QN8FaAEBV0x+OZf0Vqush+ZMt/7MGiuGFhqWvdBinx47G/zxogRYctPRFXMlCO9ZJ8KT07HLFNK0vJKrwD32H4ejkbqDuDIu4Wpzws2r+oYlGy8At7NsrppfuTyeynpExgml78iTM9K7Nyk5DAWDy2sq+qeHy7qIxTbPyTvQNJuZj0nk+yZjoHm+iAwYBQv1G619mQoz6eQmwW99C1qfdSx+LlUiB8ixA0k= 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 Sun, Mar 2, 2025 at 2:33=E2=80=AFAM Vlastimil Babka wro= te: > > On 2/28/25 12:38, Jingxiang Zeng wrote: > > From: Zeng Jingxiang > > > > It is observed that each time the memcg_slab_post_alloc_hook function > > and the zswap_store function are executed, xa_load will be executed > > once through the following path, which adds unnecessary overhead. > > This patch optimizes this part of the code. When a new mlru is > > inserted into list_lru, xa_load is only executed once, and other slab > > requests of the same type will not be executed repeatedly. > > > > __memcg_slab_post_alloc_hook > > ->memcg_list_lru_alloc > > ->->memcg_list_lru_allocated > > ->->->xa_load > > > > zswap_store > > ->memcg_list_lru_alloc > > ->->memcg_list_lru_allocated > > ->->->xa_load > > How do you know it's xa_load itself that's the issue? > > I think you might be able to eliminate some call overhead easily: > - move list_lru_memcg_aware() and memcg_list_lru_allocated() to list_lru.= h > - make memcg_list_lru_alloc() also a static inline in list_lru.h, so it d= oes > the list_lru_memcg_aware() and memcg_list_lru_allocated() checks inline (= can > be even likely()) and then call __memcg_list_lru_alloc() which is renamed > from the current memcg_list_lru_alloc() but the checks moved away. > > The result is callers of memcg_list_lru_alloc() will (in the likely case) > only perform a direct call to xa_load() in xarray.c and not additional ca= ll > through memcg_list_lru_alloc() in list_lru.c > Hi all, I think Jinxiang's test with a different number of cgroups showed the xa_load here is indeed an overhead here, and actually many burdens, like the objcg lookup, cgroup ref pinning, are removed. Also removing an extra "lru" argument. Still hoping there is another way to avoid all these instead of just removing part of the overhead, e.g. maybe change the API of list_lru_add, add a variant using GFP_NOWAIT for atomic contexts, and on failure, let the caller try again after calling some allocation helpers in an unlocked context? There isn't too many users of list_lru_add, doing the refractor from that side seems cleaner, not sure if doable though.