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 68AD0C28B20 for ; Wed, 2 Apr 2025 08:42:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5DB2280005; Wed, 2 Apr 2025 04:42:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C09C7280001; Wed, 2 Apr 2025 04:42:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD14F280005; Wed, 2 Apr 2025 04:42:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8F6BB280001 for ; Wed, 2 Apr 2025 04:42:45 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 081ABBADFE for ; Wed, 2 Apr 2025 08:42:46 +0000 (UTC) X-FDA: 83288463132.16.F0754DF Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf21.hostedemail.com (Postfix) with ESMTP id 29D191C0009 for ; Wed, 2 Apr 2025 08:42:43 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=X0P2ELBc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743583364; 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=P1I7NeXMNkcuNFfTBD581NZoOi50eOmbz4OoopGU528=; b=KE/D/zFC7xjIsXkK4qXDuTKdZ/KFG7iVc62c40aRmAcCdkELW7p1s+RfpJjFGrnpHFlRLU UPVilVMNkR01a6neBkEKyt9AGfvM8XGFx6h7zg8V2ubomK/5LgwgmUvlBy9cBHqbzurNSI ZZISAX/483wEr9wiTQVfrkTSO5QPbT0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743583364; a=rsa-sha256; cv=none; b=YCzNJRgbfSpu4OYEdb8hzivyt1+RJuwBMQl4tUM8P7vJt6LI+NYyDfZQipUpHk/TfG0I7w aX3BJY8uEUAVgllWcACtBe0tB2I99aIKl+mogdfR5CI8a2gcBeZTCpINGG46AuSwx0xLqE kvH9D8bFHHf2gM52Kyw+SgWNR9ey7w4= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=X0P2ELBc; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com Received: by mail-qv1-f50.google.com with SMTP id 6a1803df08f44-6eeb7589db4so69236906d6.1 for ; Wed, 02 Apr 2025 01:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743583363; x=1744188163; 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=P1I7NeXMNkcuNFfTBD581NZoOi50eOmbz4OoopGU528=; b=X0P2ELBc1ezQaLycdJMdPGXR4l3LVi7trHwXV5yoU6y8bgdr5hEja6GuLEsGx5mq5F 1j2W6jX9sseXLt90l12PUzAiJ/oxM7odIhhcc1vb4fx7hapreSU9XCx9nEo2ZZhi5M1v T2wY5ExlfSiTDqQISQsAiiSLMmCISfroEz/KNIOR7d3TbrVHOL1WYLD9Wq7y8W75dfrT JA2yky9RF9yQE8UikxSzC8PQn1GljlfQdbvUdRo/nxU8T7UCBQXVXkV5TjVKXo1VRcHt fNBK6x+TwPtU+vXwULSf/JmDa1efiHFG7r+UNWpRyh0IW99MybimQ62i0vAf/7J9UWql zpPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743583363; x=1744188163; 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=P1I7NeXMNkcuNFfTBD581NZoOi50eOmbz4OoopGU528=; b=Q1j+X5e7OUPfohCMppIgyYznsVXDxf/JJs9FA+SsJGFxjFsr66PgtgI25PD0WIMWg3 EZ64Z30OwShyF5YNwIgKMJyqaDvBzvL5n5bbFpnV+YHIe0lbApuHiU0RX+D3H0o+VX9J AlMNEqjf8OOtLFIRPzXOZoWNicpA855Se0znF5yWrzbgCdjMx/aks5DZvoejD7Z8vYw/ 6jlVhalIs7BDoy+5aY1I3T7ErOr8fT4auIdAvPQNBHwfUjMcCY9gD5kbpB2UWP35dgpV JbTVL2os58lt577xnYEec96w25mnGN0Y6nRojstYzpKNIFuzOdHW6FQQ8aw5YN9xyCvP e4ow== X-Forwarded-Encrypted: i=1; AJvYcCUPnGSZ8OOk3QBwOEEQEzSrrhlGGquiHnyUbbgVHANQSev8zlDVUeHtxd/eREDROIb6VlmCGzj6hw==@kvack.org X-Gm-Message-State: AOJu0YxQLp+fhtQtXDve+mrvVjjFG0ci4swc2VrO3KxB4OXbuZ98C+Nb ztMnxQ636HLtssAMJ02FZlEoKattigr/MQrYOd75MX3BVmub+fmN0kovaS/qKONGDhh+ifV1FnK Yvszgxa5NmKv3STJ9xytU/qCFnKJ/HaIkBMZVow== X-Gm-Gg: ASbGncu4BIhmqR8Y5zJWI/ByZweBhLAEyA1YkAvVo6k7/Iqt9atUe+czv7xLlGcyZhy 2c7Af5tYeD4MNLvulImarpF5df480IZ7ZNCvGhOtbkWnGPr2NfYu6Tgs/FkYzrWayjkNsadR0kr mVsY7rlmcnan9XkxyiphYaznAElIRYkVWSaE42cw== X-Google-Smtp-Source: AGHT+IFYItNwpA/Wk64fkLYr+wxWGKsPgs8JlMhSDN7+WlRwbB7s+zxhsfXmxj67a145bRcVX0Ifs2rteI5yjKCiItA= X-Received: by 2002:a05:6214:268f:b0:6ec:f51f:30e9 with SMTP id 6a1803df08f44-6eed607395emr207393826d6.4.1743583363170; Wed, 02 Apr 2025 01:42:43 -0700 (PDT) MIME-Version: 1.0 References: <20250401073046.51121-1-laoar.shao@gmail.com> <3315D21B-0772-4312-BCFB-402F408B0EF6@kernel.org> In-Reply-To: From: Yafang Shao Date: Wed, 2 Apr 2025 16:42:06 +0800 X-Gm-Features: AQ5f1Jp1Gg98RRdYNOuPRGyWDo5u7etjGkFPUh0Mpr13QaH-ygBKif10moy_dUc Message-ID: Subject: Re: [PATCH] proc: Avoid costly high-order page allocations when reading proc files To: Harry Yoo Cc: Kees Cook , joel.granados@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Josef Bacik , linux-mm@kvack.org, Vlastimil Babka Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 29D191C0009 X-Stat-Signature: qj7mykyymmmyee83i1o1wsu7b6qc8u1o X-Rspam-User: X-HE-Tag: 1743583363-72404 X-HE-Meta: U2FsdGVkX1+cy3R7kKBgMNGUP/nuJp48QNGqxhmAwGxxHO9TArf7eY8EJpPx9L1a974gBWc/UI7n94UoNkJOX2eyW/GshSz2oBGUkljmf6SNiwwH6IVkBDcD923qNS4EEVvcAix+PVitm2bq3+/d55Te5XyVv42AJIuEdCXb98+oYToYeIspr4Pw/S+ZYI8AwlZ/oFKgPrQniEolpLCeCPimtzcBzEm+Q9tuK894GI0Cblpf+5Ocom4qo48wpTEzWPooU1DDgAAfuWgTHXGV1dCz9VxpeQdp8Y9UYg+3SplVbUQl50Go+F/TSJQjYVHJ17RhN38vx7NTZ14o7TLFHbFvV8EUDoQ9EsAI6rxiYJ4ZvL2OmmzwO/VKzyW/diC09oM/J+CrepFX3qAXuj6utj3KjXqmfSZ3qpZCWWyztBa2uTIFjhWny8vKLHIdS0nHYJxLVssPOojCyQRPz4AZdP9Kio9L4y8aoA0e3WVkn/b86uryxCiXYbHi1YsGe2efhaPVWnwaKO1d48LA0kC+hTShUoMjpLOL5cLbMxxqhOxR8oiC3lyc3QUcNeJMVQZjQfpprU7YoZO0vKsG5Ndn8qbswreyGv4NNKHBAvIvXaLaL+RXu8CIVwNPef5YWHagYGztVD53JuIiZxxGBLtPmVzqoryjeYbR/b18M9cSsM2/MRgK4mssSW9WIdDwhkb5P5NWPqkIfhTY8xRoSKAOt3SZzvdQPfjwTdqJyd8dDirdYg3yGgyGwiVFgaeMBuOR/6Ys3PmHZy07GRy6y1+4L0gGnrPbH4QzgpOPsPhv0TYuSLnD2lYOGNAHq/QVwTqbqL1jbrJR0szeADK5VIMcTEI1Mw7s5W0gAcCYtoUjHQr7D6Gw5qsWetaJTdGtPlTIJiHe3ou3a94835+JycMlx26GIkNd1YAXo2cbQa5jXmBgWejyZXbJ7wbqsFFAsWUuf8qxxQ89xRAL4wBDkRp /pUpigux d3qkCufw9kw1Zc3OxPXDO1kg3H7wvXEfobEVoTQPJsPWyBpGl2yQHQ2Wix8KhIvBzg0JxGl9b5d1BnjQHoygJUpZPrfN3LgY5/qKngJmntvC4Il8l3AHhUv+pRV3sM3JM0ORXKHieSe8ZgZnHLHwrnemhErE6MSNxuADKvDZWGvefihBYoblT6ZmTTeJCVaem84hJKSd/Y/4MDrc4sfGa9nhYy9Ee5XVuxfRoJFHWKwmnnL8VladqwWxOvNK4aJ/lrFeSZuhOPbw3cy3fgjVM3D36ZD5PgP0TlL/X0Gc6AVtqlSdKXIIZ12SxgSnFcvdL52tldrmu9kEQLpexC1RBmj+ZzIUrRyu7Vlb/2St8iq8iY0I8QLUX7k/2I2mWejjXKnRloxWoZ4qTnjBWYwq6lBS0PExsNGyYpprL8JB0I2L8tFCpAjTtQro5o3FEF3l+f2cRbQVNsazz79k= 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 Wed, Apr 2, 2025 at 12:15=E2=80=AFPM Harry Yoo wr= ote: > > On Tue, Apr 01, 2025 at 07:01:04AM -0700, Kees Cook wrote: > > > > > > On April 1, 2025 12:30:46 AM PDT, Yafang Shao wr= ote: > > >While investigating a kcompactd 100% CPU utilization issue in producti= on, I > > >observed frequent costly high-order (order-6) page allocations trigger= ed by > > >proc file reads from monitoring tools. This can be reproduced with a s= imple > > >test case: > > > > > > fd =3D open(PROC_FILE, O_RDONLY); > > > size =3D read(fd, buff, 256KB); > > > close(fd); > > > > > >Although we should modify the monitoring tools to use smaller buffer s= izes, > > >we should also enhance the kernel to prevent these expensive high-orde= r > > >allocations. > > > > > >Signed-off-by: Yafang Shao > > >Cc: Josef Bacik > > >--- > > > fs/proc/proc_sysctl.c | 10 +++++++++- > > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > > >diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c > > >index cc9d74a06ff0..c53ba733bda5 100644 > > >--- a/fs/proc/proc_sysctl.c > > >+++ b/fs/proc/proc_sysctl.c > > >@@ -581,7 +581,15 @@ static ssize_t proc_sys_call_handler(struct kiocb= *iocb, struct iov_iter *iter, > > > error =3D -ENOMEM; > > > if (count >=3D KMALLOC_MAX_SIZE) > > > goto out; > > >- kbuf =3D kvzalloc(count + 1, GFP_KERNEL); > > >+ > > >+ /* > > >+ * Use vmalloc if the count is too large to avoid costly high-ord= er page > > >+ * allocations. > > >+ */ > > >+ if (count < (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) > > >+ kbuf =3D kvzalloc(count + 1, GFP_KERNEL); > > > > Why not move this check into kvmalloc family? > > Hmm should this check really be in kvmalloc family? Modifying the existing kvmalloc functions risks performance regressions. Could we instead introduce a new variant like vkmalloc() (favoring vmalloc over kmalloc) or kvmalloc_costless()? > > I don't think users would expect kvmalloc() to implictly decide on using > vmalloc() without trying kmalloc() first, just because it's a high-order > allocation. > --=20 Regards Yafang