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 9DA6AC83F34 for ; Sun, 20 Jul 2025 02:55:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2680C6B0096; Sat, 19 Jul 2025 22:55:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 240076B0098; Sat, 19 Jul 2025 22:55:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 155BE6B0099; Sat, 19 Jul 2025 22:55:04 -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 EF7C46B0096 for ; Sat, 19 Jul 2025 22:55:03 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A2D0DC03B3 for ; Sun, 20 Jul 2025 02:55:03 +0000 (UTC) X-FDA: 83683126086.09.B573A2E Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf27.hostedemail.com (Postfix) with ESMTP id F41AA40005 for ; Sun, 20 Jul 2025 02:55:01 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=E53V8Rl2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752980102; a=rsa-sha256; cv=none; b=3ppgArmR3s3y74budb3giFIB3eynDl8IxqSfgEz6Wt4q7KGO/95UYsggq4DkiFdO2o1fX8 /4CsRYVy51ry96r9VeBi268cW7JJNWMZ6/61URtMAe88OZews9Y6MY/1B/pA2uwvUqcTHT cWw+qh+gLKhCLwXXoDalxUEmEkgtJo8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=E53V8Rl2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.219.47 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=1752980102; 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=zX11vKBCysocgHYMHohidSw+dzLEB1lgHwI3wsOdYSo=; b=jEJv8IOMBclSPMXnkKcNqZ1VEkY2R4BotnmfCwG33RJY/a/lIPMZt9bO06hbVAd3+SRpiW 8zxYcZoJCqP4MCb9ziFdogP9xJcCx5TABw76WfPc91BplymGBX9WuQZ7tW2mMYF6hFTkmj DemNYAJihZ4svlyWVOwUz+RTWjXgxFg= Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-6fafb6899c2so39397256d6.0 for ; Sat, 19 Jul 2025 19:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752980101; x=1753584901; 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=zX11vKBCysocgHYMHohidSw+dzLEB1lgHwI3wsOdYSo=; b=E53V8Rl2pXibt8fdVP32BB6MaoDU3y9xMZi9wwRAZEkR7Ec+EDZyuR0LcXnSaYW+Gr EYIs1MjbHHv9t/w1F/6RBd6kG7kb/NxDtMUi/mR+K0V0VKg+RuJ9itSp4xC07CDvdgV5 P5VZ45AxVEW9AALRuvcHtWQCwCAG0w3tGkrlzWTBL/mmKsvkCn6vYfdKmxUp3uX3nfSR Jqkr9EIcbQfvcipwG7aGDSVyMWuP06lESzOIOCQJsfTCPbzMAXzIdDE+qxqMzjUaZe2i 4TH3k99DhQDIVQAgsiCJBXsmJXt3veaVjQ3aJh6XTQs3LZ+c+qHLLqbzsRAGRyoJzeV0 XxaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752980101; x=1753584901; 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=zX11vKBCysocgHYMHohidSw+dzLEB1lgHwI3wsOdYSo=; b=OGSEX33O0r2sE2xZb/s6qHXT20S+3pZRjD2yvUWJ0qs3zGk3C4VANTicE8acuq63f/ hMIhHvOlP747mJ0xa7d99j/44Cx580GjS39KBX+qMRIkOUtN0b+y7VzLTX6Aqj5luuxs D08UZKZuGQcmvKPRCciTNbMF0UJc4IZhCM3zvQNPJpHpBdKL80ldfvfdKaWti4RqmG5C ZDHaEzea/Uz2ho24RVl5hZpuXEpQeatvI7T0PWhkDo/ZfgSEPWkvB9F3JGiirANOE+qT vC8/YBUvs30UwF8Gzvf/l514MoIM6b9DDEqzkWwCqIhnimfvNfDya7FsRRMmWyVlrtiL t/KA== X-Forwarded-Encrypted: i=1; AJvYcCX5qyc/o42+RWKie93nyDOoLTfMpqgbXixEznFo6H4LJ01ZahO0E0W/KnSKfjoHDArVcdN00LCT+g==@kvack.org X-Gm-Message-State: AOJu0YwaVFxY5JOJOMhfm1QOi9zHe/nLIvRmird0GFpajYJMKA9eBjdQ 4qBIW0vl79078dGyUdtJYVMGORfTTq/Bmj/zAvmuWkViaoYgO4Y1S+tq/mvgsQPAzYbISuov9v3 HGxfC5QpmzfQhCJ/D6vdOm96n8twR/co= X-Gm-Gg: ASbGncuMEInxq1uNhPGOA2SD813dlRa4GZnZqxDAdcNpgsiyo/qVTW6pokOvgyDWO3l Hp+wOqJKFzWHPw8Kl1mECThn64vuOoV8XqAKS5n+MH5CqTjeNCP0zMFLfq0nfpdobosy8hIunFy Iyrb7yi4ktYvaNojJ/2pnUeY0d2L2VyJH07PQArn6AGs1tuibF9Tf7qjrpaQZutvEgRnSa/UvQB 5yYM4e7 X-Google-Smtp-Source: AGHT+IEqkxzgL3EifIuDK9+PCSK5zzRyf16sBt79/kqd17Yc5iGkL2o8zWNznA2b4zWQHRCwfFIU60yjNfcoa1HjMuQ= X-Received: by 2002:a05:6214:8112:b0:705:1833:b445 with SMTP id 6a1803df08f44-70518341985mr75698986d6.4.1752980101076; Sat, 19 Jul 2025 19:55:01 -0700 (PDT) MIME-Version: 1.0 References: <20250608073516.22415-1-laoar.shao@gmail.com> In-Reply-To: From: Yafang Shao Date: Sun, 20 Jul 2025 10:54:25 +0800 X-Gm-Features: Ac12FXyER6L12_yClzX9RR80E5woyEpL84py-f44N5D49vf9tZtBvezTgzP_yEo Message-ID: Subject: Re: [RFC PATCH v3 0/5] mm, bpf: BPF based THP adjustment To: Usama Arif Cc: akpm@linux-foundation.org, david@redhat.com, ziy@nvidia.com, baolin.wang@linux.alibaba.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, hannes@cmpxchg.org, gutierrez.asier@huawei-partners.com, willy@infradead.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, bpf@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: yji3snw9hci8fruyf1499u8f9t3axmns X-Rspam-User: X-Rspamd-Queue-Id: F41AA40005 X-Rspamd-Server: rspam02 X-HE-Tag: 1752980101-458754 X-HE-Meta: U2FsdGVkX1/Q7CDGARvCVuHopHLt9UZy6gvpUU+ymevEF/Kr1MojeseyRuumr2S7UN2SdwVjNq2VMyWDNXdcrUXqRiihhezvE4KLTYc3ti1ddjH46pEm1wJ52VVZt+nxRZHVxy9c8+sWXBwXuWcLWbjeU7lShx5/pf3dp4dEm0vlrkhZ0om5xfLrMOGMvsbtgJS/FuXquHwpe9hUOACRV+6/zD7Ajr59rCRKK3C4DhWePsM0lQPuwvva4Dlx2JU5wpx44oQt8sVD1WJe4NPoMukzDIJYHTnmFLDjoz/lMi0oxNfja5hFIMdMR0Opb+XSgmIOVQ4WHYWyNW1FJROEriLQDCnIwB+ctAGsdpkfHPzWWANQVz2EqI/TRwTsJLwNy3CTwqeTPsOHUoYqc4UbdkZjsMydGJExxGsLR7wuHHvfqEPms2By0dPjyceq16fSbQSQ9iyfuX5M+De/OPAy+6m3mtouQ3W2oXkMANI7MTeS/4D84cQJOsufJyZZQo1tDr73dqyxQXZ/y4hzhKZJkCZS2nY5mK37dnZXPxtUI4n9g4y8t3A4GkEFWdjkR6cCGBJrcXEyVNPbvXTlmB72JhHZhrXlh8pSRL0idNbe2+d0Z6CYTBjvskIzb6lDjDKZzHl/TPfUTk1Yt9Mag7hLMTuyS9jBY8hlyURXqy0Ht6xRUegGPit3UIH+YQl5CuZig9Ute+/OPBp+m9OPGl2zUszYRklZyP+TF25DAY84mYvgMBiFTtiJC0v3sIM5ZJjkXuK3kM6jMvaS60/LkkUbD6WNCHCRhz6fIvU7dly4Ky9pYJwEsz+ACAOnGT1YjBm8BZORxGRcVPOQ+H+V5HBfF8L0V/yBALQ98ABlw3sKRnzjbHvhjtopSDd8jJkex1CVarJYtFEPvZNazSmuQoqu8IGHxK2TzCPGV9KEr+KJnXbAPr8utRH0rP8qFdWmeAqMwWQtQNdEHaGBs3NvJku q6iG8xod r9JaKn/ZJ33wDfI3ZprCDIvTuXF8YaGWKk7Sx5QC92eX/w/U= 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 Fri, Jul 18, 2025 at 12:35=E2=80=AFAM Usama Arif wrote: > > > > On 08/06/2025 08:35, Yafang Shao wrote: > > Background > > ---------- > > > > We have consistently configured THP to "never" on our production server= s > > due to past incidents caused by its behavior: > > > > - Increased memory consumption > > THP significantly raises overall memory usage. > > > > - Latency spikes > > Random latency spikes occur due to more frequent memory compaction > > activity triggered by THP. > > > > - Lack of Fine-Grained Control > > THP tuning knobs are globally configured, making them unsuitable for > > containerized environments. When different workloads run on the same > > host, enabling THP globally (without per-workload control) can cause > > unpredictable behavior. > > > > Due to these issues, system administrators remain hesitant to switch to > > "madvise" or "always" modes=E2=80=94unless finer-grained control over T= HP > > behavior is implemented. > > > > Would this solution work and be carried over in fork+exec? As that is som= ething > which is very common. How would that look like? The current implementation doesn't handle the fork+exec case properly. I've developed an updated version that addresses this issue, though I haven't submitted it for review yet. In the new version: khugepaged_fork() will verify process eligibility before entering __khugepaged_enter() If a parent process loses THP allocation privileges: 1. its child processes will skip __khugepaged_enter() 2. it will be removed from the khugepaged mm_slot. 3. the MMF_VM_HUGEPAGE will be cleared --=20 Regards Yafang