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 F2717C47DB3 for ; Tue, 30 Jan 2024 02:12:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DE958D0002; Mon, 29 Jan 2024 21:12:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 671C78D0001; Mon, 29 Jan 2024 21:12:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 530C68D0002; Mon, 29 Jan 2024 21:12:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3C9288D0001 for ; Mon, 29 Jan 2024 21:12:35 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B26E9C026D for ; Tue, 30 Jan 2024 02:12:34 +0000 (UTC) X-FDA: 81734353428.28.8A51A96 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf08.hostedemail.com (Postfix) with ESMTP id 046E5160017 for ; Tue, 30 Jan 2024 02:12:32 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QRtNfNCC; spf=pass (imf08.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.219.176 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=1706580753; 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=oZNQuCd+KN+iEabO/fXy/33O6CPWq/hHiiIIZfw1y7w=; b=W3a4IA1WariwL2VULxchN6RVLacPDMfid27g5loMW+WIEDSgqHavFqxuVxSL9qPuAO7ES1 I/RRrZ3NuzYUDABFU9EZpZkERp4ZoYzHMwyNLJnmED0cyBNf52hqUHvDwwqFWWQEbuD+Go DQ9ZhDbr9cdpHHQ0bvA3QAyRq+v455g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706580753; a=rsa-sha256; cv=none; b=cIm22i6NZDzjwIsG0HjsU92W8XI762WMzGXwe1RSCBAao5wCRvKwmf8sZcctDdbpw7uBf0 3Z6pdXAp8CbypYbV3iA8OLb3QWNzxl6T36bgNyXXkl/p/sW/u1H1RgCz3qYUZNjBB4DBnd BIg2r0wrZzQUe+JkAlpOL0eA1mjjNyU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QRtNfNCC; spf=pass (imf08.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-dc22597dbfeso4360746276.3 for ; Mon, 29 Jan 2024 18:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706580752; x=1707185552; 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=oZNQuCd+KN+iEabO/fXy/33O6CPWq/hHiiIIZfw1y7w=; b=QRtNfNCCgCPBCOkFr+1ivpTsWT8/t3SWvWWWlalYpqphayH0YqRF3TB0duh+P8QiB9 T8lH6SHtJh3zrmglDkYxofpRqafCIIcLlQr5nEtjPisTy1n3Vnf5sH6y3NTn+WZ5l6Tu p+Kor5tZpoYr7hJtKo+QPC49mlimgqzImGuRRk6rkyFjODnNwlqtX/Uue3a4C+kemvBZ SUpjuiLkikXypzT9pnPBfKjPASoGitwU0hhtXSHVZCFLoqm8Jc1DiTwfi1g0W7oU/qTs ofLT5QEwVWSt8OzRmWP4PAT+37ExzgR+iD9xBPLKDInQQCCf5omgEghphtBZgfqK326R 8eeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706580752; x=1707185552; 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=oZNQuCd+KN+iEabO/fXy/33O6CPWq/hHiiIIZfw1y7w=; b=XhXuP1eqKbs2nv6XS51EnlBkiHFxJ4HHjHnn6BX9dHnnuGal+Z4xWUAqyyCRYD7qS+ yB7IktZBDwOLS66udWnar4IwY5K9uVe89IeIn9bKAHsfSWqWDIQkxPZZyJGQ4i4XkEPa q7z86vRl88eor/qMUJc2RRt2ECGHH5lZFvF2ui+CJ46ULZsh7GZSfoCNuT+5gDmstHhb lstmZqPEo5PzA6HEhN+Jte4hyaJ0CH55Fj/56YKOZLRw837rqIkcRq+mPb5ED81M8RHn pO/eCgL+6XWlYlo9wSxOp58gSTScMHIk9tZBznNpWUlo58apPr3i4SfrDZp7vtMNTkRB L8XA== X-Gm-Message-State: AOJu0YyupRUJmEJTq/Kc1kyNjk1Hn/p8g+UKuHG0s5qR9fL4XhSLkbph OjbgmYqqSaqI8YuXieI9uDH9P5iJLGjpnO8TYYdX3a7T6hxMG0A+lWW7irW4pFid6MHQ9Cyq4X+ vv+rIYtgid78o2CqJyc/sGXVeM78= X-Google-Smtp-Source: AGHT+IH4YpNYxj/YTJJmjFy7lceiIFbPIZFioZHoUUoLFJYustUJM2yT8NHGwZL0o/WsHLV9Wd4Mfjx+GVfwnbRVfcM= X-Received: by 2002:a25:f449:0:b0:dc6:4582:2bd with SMTP id p9-20020a25f449000000b00dc6458202bdmr5297622ybe.76.1706580752116; Mon, 29 Jan 2024 18:12:32 -0800 (PST) MIME-Version: 1.0 References: <20240129054551.57728-1-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Tue, 30 Jan 2024 10:12:19 +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: 046E5160017 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: mo484ejfy5rskttk7xyyab113oqmj5sj X-HE-Tag: 1706580752-960557 X-HE-Meta: U2FsdGVkX184SPeoRQMC8E71zr+ejt8nLn1kLTx/EYtiQXXEVjlj/p/u5ZByjVVajzXZtqsAYIfsrig/THpKKSC6NTk6uz02IJyp5rQZbbHNxEPnA8eXI45nwdusE3KY8uxOsKegfVQRsKYuKytOg9pN1xWbqWSH7cmTpFvBJz6hLsgI14uv/gJ9RV8Vsps5MSiDYUV7JgUfohMQGn9Na6GueCY848DfSVFngQmALMXO2+TFZA/wp6PhfjDFASdYPQ4CpzxwzcmI46ipuzOH+JFMb6mTPfgAvHF5A9J2kD/KvpPLebrxArb2dYtmIs/w+zOcNUKDtzJqBKI6u/cuR26FGTmpWd63+6zg69SD8RpWWyHKZa3lclWgdOKhMmPepN4KM6R44zjjNiKvYD1fxy6ohjWeE/gDRhGvIkAYhpL32n0OiYoiIKWoCaMttNELxCbw2R2KfZopSaphOSyxGqPLbFTb7WSxXdLBLOktUc06jchnjVzy5L80AHdLkxUkLPZ/OPaQymT5sVaKQcs4gVUOCgsCtVfb667sOuZ6/M0S/6ss0CN0HeuCDH3qB82Mw6FQCy8jp5/7/jxXQuQGWf85fDiJuyofLYXpLYY1+DQJxW5o6SXJKrNWjx/7QuZ4i3y/HGCrBtH/KoCMeOEz33vlFt0hBep+OwE3dpKZicFtYL1q1JdjrIApxmOKHsqMcXm5MJOdBsbyphiduYBirvMm/ZwDowsW2vH9ZIRFqXkeSZ8D02D4pBH8oafuK/WQO4KH4/XzhB08Ivlyr9f6z3CqaN3fX6ACxtPC+37xxLZzRcFV66wZd6hFj4adf+BDm84U3mVW1V6NRMvlJITHh5c2+ZGb+N3mT5abIxxe0nMCsUNuRvdOMOFGgNOyALpX62YVrCmiE2DqUAcNFe63RbSLS/g6JfYN6rA2yXNoSJ+2CwE7IQ1zA3+9cVoh74EvdGFgOTXn4NbI8ZRWiSk Efh+g/Ae N72qikdDNI5Og4C9RCZcpWSRGe2FbbgdaUwtKsSPkkazf1kg65rL3tUB6GrCprBBIF1FHRaAKnk5+BMS5qJ4Ym3SFLOe0U50IETbzWCTsL5a6YKhn47k7qLMgsaNA1DDBa2kQOveEyNdjkqcPtI5o0B02z1X6qi2MsVih9za1XPVsR8O5vimwVqEqx85onoMj9fNWygF0u5wOYuT77RDm/g6wt0paE5VZ3wxu4UTfz+9815aeSq3yu5lzpuN1RhyFG93VBSyEe2EJ3oXeLv9ljfi7LsgEn667HENO23z8PzhvNlWpN2R4v9M+Fkb1sWH7xFTZqJisQ0+04/EzM4Ogzll+IOMNO4+F4jdh3HhruCL8wFD3T+8pbYkeNG6NuBJIh13vXZvyBvHZsd8O/DOif/8vT4UqYbfYFuQL6Re78iQyc1Sv5am8I5mH16ND4gm2I+x2hqHuVWjOqgA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.019964, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 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. BR, Lance On Tue, Jan 30, 2024 at 12:28=E2=80=AFAM Michal Hocko wro= te: > > 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