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 BFEE4C47DDB for ; Tue, 30 Jan 2024 03:08:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41CF56B00B1; Mon, 29 Jan 2024 22:08:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CCBD6B00B5; Mon, 29 Jan 2024 22:08:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 294396B00B8; Mon, 29 Jan 2024 22:08:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 168FB6B00B1 for ; Mon, 29 Jan 2024 22:08:24 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AFE32A01AA for ; Tue, 30 Jan 2024 03:08:23 +0000 (UTC) X-FDA: 81734494086.12.AD0ED63 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf16.hostedemail.com (Postfix) with ESMTP id E4FC518000D for ; Tue, 30 Jan 2024 03:08:21 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Scrxouny; spf=pass (imf16.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=ioworker0@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=1706584101; 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=kj+P9xrjx2fVS1ypKdmJNYGvbVzBBTf7MJvPcLc0yRI=; b=vHZfWaAvuzLgpRZRV2KS+5V4vjDPgaS9buKlejmRMNn3nH7oGacSE4xCTKUMafkTxuaTKY MV1u8aiPpMoXrDJoMYCeI6B0ZUZHMCRJta0UB/7oAwmSabHGQia7tigVeWJ6Z4GU0k/exi QdyltJpKinWMY24BgAUmEHyXEsI9FgQ= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Scrxouny; spf=pass (imf16.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706584101; a=rsa-sha256; cv=none; b=k53u/Eg7CX3CMNglu75ajUPOL9XbAdzHcPWYsAfSGQ4xgcXm91eRsFsZa8hoTX/7Dc0wV0 DpWqFJJD43tt7ROeIUL3fwDnnKUpbdb9SCyd+Kf6o7WrntqN4P/6LJUXfJvRLONOoM/VNL v6ANzKRArXJkoKiK8fQm7UFCyiqIETc= Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-dc221f01302so3309357276.2 for ; Mon, 29 Jan 2024 19:08:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706584101; x=1707188901; 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=kj+P9xrjx2fVS1ypKdmJNYGvbVzBBTf7MJvPcLc0yRI=; b=ScrxounyT3HMQ7NshrWGLhKa4OVNZJk/pViJf7FYg82WkJmZp0J+j8FiudBm9/+hE6 p8F+BvbqK/yLoxVHN/BN7MbSb+bg095kyn4tOjrrBs3TgGQUAh+oFCqVAcHat1+KQSQe wabI9Nw/862GuWnRD0JePG21lKa+vIW9cRcHMgYcva9O5R3VHkTX4ESIHwFYYjpyeuWK 0bexS39QpoID6CwfVHliRXd8B/0Bnp6rvZHPDFZeV7uaXeEN8c+AB4U67k01927aAtVE bSShuUPw7RrvwTWCtVrNtGm7KVXWKhyTwOO18Dop/5lEzIvEs8Vm91v43eBmroJySGnc PIyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706584101; x=1707188901; 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=kj+P9xrjx2fVS1ypKdmJNYGvbVzBBTf7MJvPcLc0yRI=; b=TqlrwMvdfNTHqpxwAEDW8EgQchcQQaEm5eDwhfgaK7zvzCJrZDaARUQzjnqc7unusp B9ZPkTpZSoQA4ihYpeLNGOf/DfLO330/hWF+1o0qoGk+pQkUqhN6v0XnbByHM+gRxBi5 58NrnqqZDwfwMgvTb9JLS83D4CHR+reWZFMAWTrWARDwcLqlwVaLfhuhUiw8/RSNyO5J y5bcaFRhfD+D8PGGyE3T3JQbHGXwsDu7YFiEV19CNEHibqGfMwAFU/a4mmSLagmNd9fY W0Gj3iVMgBUpDSr8l89OPceJT1gN1hObcNw+bhIrnz2aiiXh2RacYslV9ilDUbYwS5O1 4YUQ== X-Gm-Message-State: AOJu0YyUpArZZ/KsMR8bUTaYVEJvi2IWRxSIusGDx84R6fcvrguIO0of bcF7C5FdrUltxlZ3BhMulVI1yLARYwdq15wFwluTwF8NT+pNcjZz7tSwmtho4hqANmzCBMQEp5W ZC5XLDyTppyfnN460ueajguE8jv4= X-Google-Smtp-Source: AGHT+IEUBwGdagOtNNDXnC/PkslqtTnUcalzOpaQ6iXfk8Y75IeUUiEjJkcKdHRkmkh3SiBuFcgOP3JPXkmJHjLmEC0= X-Received: by 2002:a05:6902:2307:b0:dc2:252b:d937 with SMTP id do7-20020a056902230700b00dc2252bd937mr5586928ybb.60.1706584101022; Mon, 29 Jan 2024 19:08:21 -0800 (PST) MIME-Version: 1.0 References: <20240129054551.57728-1-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Tue, 30 Jan 2024 11:08:10 +0800 Message-ID: Subject: Re: [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with MMF_DISABLE_THP check To: Michal Hocko Cc: akpm@linux-foundation.org, zokeefe@google.com, david@redhat.com, songmuchun@bytedance.com, shy828301@gmail.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E4FC518000D X-Rspam-User: X-Stat-Signature: 5erce1czacort884yu91rwu8uukbzbzy X-Rspamd-Server: rspam01 X-HE-Tag: 1706584101-721296 X-HE-Meta: U2FsdGVkX1991ehGXChtHA0zGGrhP2XfCe+iY4lDSNNRMOHBn602jwlagQEwQY7kMFkDgDe7WDj7B1jGmkZmzbVdeBZP084vwWUgmjvDvfZLqMDp3/TuKgomKbXFtlFyElmicvdJaTHlIzA+SVfbe8WPagTYN3KUlcoFZgxevbztEoT/IxQ/xJSThp+vcOnfvDn1PQktoLsCQJLRhGXdLl4kPD/VHKTQcctQq2EwFLSsLaOee5dj/FOVIpmphYE6aBEvPQAOgMj7oe7ocN/8UWAsGY0ivG9yHQ9hlVE5NewnEJK8MGY9sdlYwHhzdwm+qmesAh7l3Mcthd1X1r/SOu2aGXJaWB61JUpuAG+7t1mXxXH383zGeFs3KAuJrRklflcbL/AoFGar6C5XvRjjqB9pIN4UfaR6L68VkbYhXkCoGkqVYfY9dkCyc/PC29loY2Nrr2u4kkIWVfhxbicdlAVCaC2VWOlAIhuSExu9XowGfMtY1P1dYX9Q6Nuy7cEIc21XffK8UW5fNF68X78aCs6oKuCisZ3Xs9gfQgTb40HFC+TqjRrCVpIVGxXfgqG5tN34k2XVPEMD93CdZlCD+Ty9LXhIKoSAXTFpjvMcb37ynL6+AFW7NyZAwVRvuSPcf1kP5eHX6Wz1YgAebdUL28T7kefHHHygZ2J2dHO4zTfS1ksScfie86KHCw3S6S3fP43oyHokHiD2tZeAwijSe2sM+sSVGpEmSHp2u+e2Jo6bNkBDEi3ekRhnznZnAbAT3SDlVqTZgpF7qKDtAUtZoAoc78TpYbEU/XerHLNVgFf/zxwxl6do4l6qHAAJxD93DYR78lX6FuUxgKwaa1GUh/Z4pJCksNVEUajaRrqdTg4J1Hm0oFfugeCj3WEfELw7xpqWFnW++fa6uqHQEl180/ZNGL5p/p2rVQ2CGWmsA1GOIb//+7vwKjXuS09y4vU/NJn3TBSL0byDksMsX5g C47EFE5P oXqD9N55pt61306qR4yCDIm1m5dxXEFmHJoN2mqYOa7q5XqCQg2M0SyLOiRxZcNcjndoAteP8A2p3SVliGj0c6QXl6x20odszVHDadXpkxf2Av/Y7As0XT8LK+CMhnsHe6MiT7jvi/2L5ANepNdfgGPmcyXoHM5Cneu9nlgZBIWvUtNl50cEqG5iyMmydDTa69DLBZeBue2aFC+pCXqw8tp+O7vaK3SSJ3Nu+Idysn5kjal0CW2ofMMfQNFGZ0igkgp9bYurL+39kzdWt3zR1+fD5l1DDMOqLYIqLiA4aefqFQd65++lScgebq0+nt19tXKWJN6MlUfJAVm35vchoL6TNz05lMkXBn0VrhjmnKz5Rlq/zgJ/wFs1DoJl3Q0UgrVMZvDvNbE3HyynDBN0r5PQ3Du1ZhE1vDjOJYLDIyWm2HuKtu3zIFojUE2IDJtNoIEgLStYrgpdRVLnaGFxpwysod6E2MhrEOLlPOxraV/DYc4A= X-Bogosity: Ham, tests=bogofilter, spamicity=0.192022, 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 Tue, Jan 30, 2024 at 10:12=E2=80=AFAM Lance Yang w= rote: > > Hey Michal, > > Thanks for taking time to review! > > On some servers within our company, we deploy a > daemon responsible for monitoring and updating > local applications. Some applications prefer not to > use THP, so the daemon calls prctl to disable THP > before fork/exec. Conversely, for other applications, > the daemon calls prctl to enable THP before fork/exec. > > Ideally, the daemon should invoke prctl after the fork, > but its current implementation follows the described > approach. In the Go standard library, there is no direct encapsulation of the fork system call. Instead, fork and execve are combined into one through syscall.ForkExec. > > BR, > Lance > > On Tue, Jan 30, 2024 at 12:28=E2=80=AFAM Michal Hocko w= rote: > > > > On Mon 29-01-24 13:45:51, Lance Yang wrote: > > > khugepaged scans the entire address space in the > > > background for each given mm, looking for > > > opportunities to merge sequences of basic pages > > > into huge pages. However, when an mm is inserted > > > to the mm_slots list, and the MMF_DISABLE_THP flag > > > is set later, this scanning process becomes > > > unnecessary for that mm and can be skipped to avoid > > > redundant operations, especially in scenarios with > > > a large address space. > > > > Is this a real problem? I thought that the prctl is called > > on the parent before fork/exec. Or are you aware of any > > applications which do call prctl late enough that the race > > would be actually observable? > > -- > > Michal Hocko > > SUSE Labs