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 BB078C47258 for ; Wed, 31 Jan 2024 18:47:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 521DF6B008C; Wed, 31 Jan 2024 13:47:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D1C06B0092; Wed, 31 Jan 2024 13:47:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 399BA6B0095; Wed, 31 Jan 2024 13:47:05 -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 29E806B008C for ; Wed, 31 Jan 2024 13:47:05 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id F28D8120814 for ; Wed, 31 Jan 2024 18:47:04 +0000 (UTC) X-FDA: 81740488368.28.1615805 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf13.hostedemail.com (Postfix) with ESMTP id 1FDD820014 for ; Wed, 31 Jan 2024 18:47:01 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WRxucjBE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of shy828301@gmail.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706726822; 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=Up3uofbpHbcgfF19VzZ1HsIvzv/qL2Mf7ez3FTnsd3E=; b=NA6kV0Fd47bN/gVTuX7m6sfe5yuMMNKRIRpQC8ZKGZUpmYOM6pv3C2u1J/npoWcORNG0/U i9u2DEDXSCALziDc++18LNPEpSEc6jivSBLvg4bvomdiHKKOvMvwj7JQXKBwt6Iovk6vqA P0g8cudQB0GWL1uCxNnILVm2y4yR9Xc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WRxucjBE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of shy828301@gmail.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706726822; a=rsa-sha256; cv=none; b=rqissmZlV6ft0ckP5BSOAmrrmgQD8hYHpeB85+kRc/CFvTA2hpksfq0tauHmArIsy138KC GpEgThtV83Ur4k8zScWRi5XRnK6I3FSy0A3quqrI+0aVavPCO3qqh4GmI2tE/GNZAXeOJi DlAnRXwUmxV5VYaWse6rttfnJlaTHoU= Received: by mail-pf1-f173.google.com with SMTP id d2e1a72fcca58-6ddc1fad6ddso46391b3a.0 for ; Wed, 31 Jan 2024 10:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706726821; x=1707331621; 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=Up3uofbpHbcgfF19VzZ1HsIvzv/qL2Mf7ez3FTnsd3E=; b=WRxucjBEysMioEN8k7JFFJHPLwW1PcUzB+jFuEJ/pqEPAvAnGAeKG01Fgp9aI3vRtu 8uRs9tEbBQD/ZGIkMPkHa16Oju6a8lQmRDPr9ftVrCSKIpzgujKuz505IoVaU3pVeQTH TnI02269tFx4WD+hDS8dFkeo8jP4eXsi5/l5PUDOsywFrBp07+tFD47alVLqTjda1Ye0 E94X8CD+1jaL5sU594caZVD4R/I+3qVny5xod0naa6IYVCJ8un5OtjHzKrYEZRNEApD8 SZgH741q7ROMEZuLYmz0ZYIqqR4M8NGMrWofOq6kNQDBdnpAki+gZz9qT3Y9+u488PDk L6Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706726821; x=1707331621; 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=Up3uofbpHbcgfF19VzZ1HsIvzv/qL2Mf7ez3FTnsd3E=; b=JggKOLXOyphhQm/dCxGW/QVIF1Lhr23BW381PQCNK9LKP5FEN8DtjCve02hlD/VdFu R3CHqdLcpYrTOGe6Xqy3yW7K+yA/Y4Tle2rBrMHMowXM6mg+/sjdEwXHEFr10p7kQhPW W8NOQxMR+CIbzdLdF/bkPAPy/tjQB12XVny0iGjHPcWrdkUZceKYmB4vlMEOggjPn22H +5p+UibC6EAguxgrpDDhKkCurSeWZ2PtNUHYYkJhWGv6SMyMEoKbHbRQgF5h/v7UA+7D a3j8HzElVS3UNfiK82jj4FmyfKhswQpA3ec8p96sccMy5cVV+ETzOv1H0YkSlJdtGppJ rV5g== X-Gm-Message-State: AOJu0Yy5L/FEc+P0H1TPx2vbqlp6kPnjssYHYoaZn5qjx53X1mwNEnM9 4v4eNCqykWGreSrehFIKTqBesspQgmtA1eWuTrIUGJ9S8zbev0YZeEirv/33LnrHxA4LbQ5aLLW 0hSOXtTaZUlf8cFqQMui1HfTb0CM= X-Google-Smtp-Source: AGHT+IFvdMrLLs2jfzcjF2taIMDHL9UNC5E6++Ziyq/77dlIzpAy7+xkg+/jO/FfZjN2sSsEbkktYP3+0JF85l4oQFA= X-Received: by 2002:a05:6a00:23d6:b0:6db:b355:892d with SMTP id g22-20020a056a0023d600b006dbb355892dmr3120222pfc.2.1706726820943; Wed, 31 Jan 2024 10:47:00 -0800 (PST) MIME-Version: 1.0 References: <20231221065943.2803551-1-shy828301@gmail.com> <20231221065943.2803551-2-shy828301@gmail.com> <878r46ym4b.fsf@oldenburg.str.redhat.com> In-Reply-To: <878r46ym4b.fsf@oldenburg.str.redhat.com> From: Yang Shi Date: Wed, 31 Jan 2024 10:46:48 -0800 Message-ID: Subject: Re: [PATCH 2/2] mm: mmap: map MAP_STACK to VM_NOHUGEPAGE To: Florian Weimer Cc: oliver.sang@intel.com, riel@surriel.com, fengwei.yin@intel.com, willy@infradead.org, cl@linux.com, ying.huang@intel.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 1FDD820014 X-Stat-Signature: p9qwco8okueu3thxt8txyw9qsozsecan X-Rspam-User: X-HE-Tag: 1706726821-347677 X-HE-Meta: U2FsdGVkX1+9+SSAfAHVmQf5BXLZ9EaNgSA4IXYGGz6HUrtwAZ7yZyIk+oPKUo3x+kQV/7QylB650x2Rd/uPw8y+1XedJPc2ezKGxfarOTbhOnLtzoo7d8Qh+/6KXuRyjY6AUC7fZY4L0PXUY0HV1QGHMIfQ6Upo3UFqJG2du6qJS4MmSpBL+2SdB3dgEb4YnG6eWOr8Vy41n5S203o/BbGuKFcCuAE4GGUbOoi6UOS7stCDjtQ9KpeI3q7AkFa3SK+7htqkG4drOd84fRAxdUdLlMR4Ecfn8+VcuegyE2U5+gK6BX4ibcEdTfNs2YSuquSJoxK0XdMnSzpAm8iqidDXyKFwDWXwkxx3ecuyaPEOKiIWFZwNLLxp5rLxGt3c1EnOv706QkGYdVVm04zuUW/s7qg/giVrhNAEEwWgh2AJhBpjBqhoYlStclLav3GawSTgeeMMR6rjWTIOkxGSqarov9HPnlB5b+wOMCSMNl89aZ6cQmIuN8ZFIxSbufaH6iJ87uJueygPmNsWJcJGuO+Q2U0xf7kc3JTkhMfHqYgD9/IyBFTsKcQKc70WmLiOI1FhOPayx1eGweiuI/oKXzUqaCRZV2+Ozb/Hcor5PwyM0KUgrPchn0nPIKwI48s8sm7oA0m5Cj6oYEG6sh54lI2tq+YkEayZexOhDWXc8PVnPgLFRnS1FYBnKArd/nSAvmDQB2SsHKdMc2NN6DzvlFneV8WlO19zkQUH6c5jpGRBBpOUIhgWmjFsPgZ7JTiEiH1+1o3Lt6Q0x7Dv25b1f/M3PZ/D1bTYrtDtik/iHnpUi5qfMiAwxKpLNwnQNZtoYNlYSRakfU10shgIoSUeFhjuYYRBpWPLZAGajza4BpUrE7V/LUl81anqC/OHEX5Z/yWwkFKINy9Eivvfy3cdEUX0vKI1OrauAszHtr8JkzP1a3zHxd/LZ1Lbd0b71oJbtF8/rv/JSm91ThOSzY5 ajX6NfoS OuNvVova2LEKnVo2tCUZzpAWZyp5PaDzhBg3+/e+W7j6tZnfbaBxonYlmJ7ohbwxyc5uK2lQyOwbmwEEPh2u49fg8toxmqz1HxdRtlnUwq5GSFHQLKk8rT2cc5TzRCSnHYHZCI3h2ZLfVyptWRyCOfADTwHzq4i2Tybhrh+rVU6r4v8qdLXxhs7wyEpZTqmREKPY1O5+JHC3xU6FjJCL58mJU29wlp/oCztweuVwJC37H5vZd8sqlMN/cveZMFb0qZ/xVtL0hcTzUwXoeq5cxvis7l42SDEPNmtx5wP0hQOWfdRPgu/eLxK1O9/SxHbspr/38m+6gLS4jqtctjkxwvzjuy5QaIjqWOeQRblZDtWeLmTyErIdxpz5lV3XRUTcjGMobV3E9xvqV5Tu/S2fFkSMeuMgG138QhC4jKcPWFV3EWrqiF0Tb6OsSu7N/xRrWd5mbt2PqAYtcwZfMzZuD2Zmmlm2dlAw0/kbi+78Xf9ghW9T8HU9R7/wqD4OpmEvj3PaiLUzS9BpztkqOH9lMBfxZ5oTrGiK/ePgXvybioZLf4BHAy3cfhTMWtHsGcuEpPp2EF7OXQRZYU0mvzqyDbCDUXu0974sHn0eo X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 11:53=E2=80=AFPM Florian Weimer wrote: > > * Yang Shi: > > > From: Yang Shi > > > > The commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP > > boundaries") incured regression for stress-ng pthread benchmark [1]. > > It is because THP get allocated to pthread's stack area much more possi= ble > > than before. Pthread's stack area is allocated by mmap without VM_GROW= SDOWN > > or VM_GROWSUP flag, so kernel can't tell whether it is a stack area or = not. > > > > The MAP_STACK flag is used to mark the stack area, but it is a no-op on > > Linux. Mapping MAP_STACK to VM_NOHUGEPAGE to prevent from allocating > > THP for such stack area. > > Doesn't this introduce a regression in the other direction, where > workloads expect to use a hugepage TLB entry for the stack? Maybe, it is theoretically possible. But AFAICT, the real life workloads performance usually gets hurt if THP is used for stack. Willy has an example: https://lore.kernel.org/linux-mm/ZYPDwCcAjX+r+g6s@casper.infradead.org/#t And avoiding THP on stack is not new, VM_GROWSDOWN | VM_GROWSUP areas have been applied before, this patch just extends this to MAP_STACK. > > It's seems an odd approach to fixing the stress-ng regression. Isn't it > very much coding to the benchmark? > > Thanks, > Florian >