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 A3164C4707B for ; Thu, 11 Jan 2024 21:31:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D3426B0074; Thu, 11 Jan 2024 16:31:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 18DBD6B0075; Thu, 11 Jan 2024 16:31:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 022B06B0078; Thu, 11 Jan 2024 16:31:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E5FE26B0074 for ; Thu, 11 Jan 2024 16:31:48 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C46281A09E2 for ; Thu, 11 Jan 2024 21:31:48 +0000 (UTC) X-FDA: 81668327496.17.46FE5B8 Received: from mail-yb1-f178.google.com (mail-yb1-f178.google.com [209.85.219.178]) by imf17.hostedemail.com (Postfix) with ESMTP id 14A6C400CD for ; Thu, 11 Jan 2024 21:30:42 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AYim1Fta; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of dagmcr@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=dagmcr@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705008643; 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=8LgYFTnwAu8/MG526Kevc0lB/NXqtyQR3bdvsNZmg0k=; b=DSYG0YRJGdu4Kkaqi6Un9vevHOfkZhN+JUZ5Pn2P0ktTdl1w7BB/01+Kj+bAX6Hdj37fxn HtD3ck6THJ1QfZ7hsdLBJaNU086oGUT2Nn3Q2V7E3ydmBvIHjk0bjS/ROrYoKn3dL7JX6y xIqh5r4Moomi2xItgxALuVYZTzyoU8k= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AYim1Fta; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf17.hostedemail.com: domain of dagmcr@gmail.com designates 209.85.219.178 as permitted sender) smtp.mailfrom=dagmcr@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705008643; a=rsa-sha256; cv=none; b=We275QLpZIA/vi5wWnqzGQ7SGdCalPF9VrkDfetOsxq48JuSzAscHEyKB+hm+jz2tpDuUr c8EO8AHLE7sUYmJ7SygiSpEbH1ONf40Ge+M0RFPHRNl/m4/4yJeBI2u6ZxE3qwHy27Cs+h e1ZwoHVDEkaVLfSwXQ5Ho156fSNpxWY= Received: by mail-yb1-f178.google.com with SMTP id 3f1490d57ef6-dbeff3fefc7so4815822276.2 for ; Thu, 11 Jan 2024 13:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705008642; x=1705613442; 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=8LgYFTnwAu8/MG526Kevc0lB/NXqtyQR3bdvsNZmg0k=; b=AYim1Ftayj5yxpWpncoyQpK/ektCq0ZUPk3+7aBom+Ftl2W8SIMirQVk/ZvtQeQDs7 nzzp8ZVDlGv2+6VcrhSZ4AoS/TwgGw05kn6HHqPi2PyfYjwB8RVEqewPCCuUCGLA7Q/d o9RM1p9ziM95Qsxk11ea8WVd3TwHVl3tuEgr7FqH3+0/5JtCMYzlI0ipPWguS78kDjn2 6JpdC5Pw/V96hU5oIjrBwLnMQ7xFSdkMcrVbpexKOW07dRTB9PO2M7DxSIcgoUwVG3N/ L+5IbDJWkanTuh8bw/qO9h/RpF6LftYXkohSBKsMzssXWzddloc4sPJOxUIZbEtLXQ9d X2IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705008642; x=1705613442; 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=8LgYFTnwAu8/MG526Kevc0lB/NXqtyQR3bdvsNZmg0k=; b=jYdAyN8n7q5UMShDc/qtPNqi2RIl7V8Zm7OAiyfIKbDolyEnf/C62yjcLDvjGSSYEv wu0DHFeF1fvGf1F16Sb8iw0Iptbk89ifR+LtwRSpqatG6cMFfsp0DkGq/BlhqI3qGW6Q gMt0Dju4ve9KnO0f5RaVS0R67GjZXDqEDqmegR9fNY1Seg7mUMtkerksMJz3z+tIBfQA Besv0fzRBHezJs198H3EmUIR73lajdbS+ukuCCrtfvXhQJnJiWglLTJuuOlNqvtQmimq Ob1G7Mu6FFvl60rapNWEoNJkb3ob2M0j5yyOMm3iBG1J7IYbqzznHy/6j8M7V9WNvIVI b6Gg== X-Gm-Message-State: AOJu0YzpvoO/RTQiso7aAgMRbuqNjD7xWElUy4lHCBLq+bwxiww9/yoA 60CEnPZeUZcF5caxpyIRlr1Umrd4uzi4DMDzXe4= X-Google-Smtp-Source: AGHT+IHwmH+A2IQ0AogjWxAMvzBiF3cSFHiqvOmPkUcvH7iqX/OVfLICPOYHsW9aFA0OozZ2CFnaG7nwOMzm3wCWY1Y= X-Received: by 2002:a05:6902:1364:b0:dbf:11e:d09d with SMTP id bt4-20020a056902136400b00dbf011ed09dmr294814ybb.84.1705008642089; Thu, 11 Jan 2024 13:30:42 -0800 (PST) MIME-Version: 1.0 References: <20240110092109.1950011-1-hch@lst.de> <170490002493.164187.5401160425746227111@jlahtine-mobl.ger.corp.intel.com> <170490050245.164862.16261803493864298341@jlahtine-mobl.ger.corp.intel.com> In-Reply-To: From: Daniel Gomez Date: Thu, 11 Jan 2024 22:30:31 +0100 Message-ID: Subject: Re: disable large folios for shmem file used by xfs xfile To: Matthew Wilcox Cc: Joonas Lahtinen , Christoph Hellwig , Hugh Dickins , Chandan Babu R , "Darrick J . Wong" , Andrew Morton , David Howells , Jarkko Sakkinen , Dave Hansen , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Christian Koenig , Huang Rui , Jani Nikula , Rodrigo Vivi , Tvrtko Ursulin , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, x86@kernel.org, linux-sgx@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, keyrings@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: e16i7naphbi9x6pae4tagp6a1o48mt55 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 14A6C400CD X-HE-Tag: 1705008642-947021 X-HE-Meta: U2FsdGVkX1/xTF2rs1AVtyOTk9LCxxMduWL5Tyo2oQlNssk9c3fSUmMqAIHGozSLGPogMFz12yYFmR2pG5Hb7UBIDoC7xJQHj2VdQzUWHvf4rpunfbqkzf0iFB8ytInzlQhZBx7pLHvlz86+2TogCk/WSzRPa1e3tldZeY/ymleRd0+3rg71UKEa7ktlqLP3anQxYNbYnStdxncgwOJIPX7NLEj8Aa8wbvKnxUNDlOmFYps/LcrUCtjLNha5XxOxctvawVvKHpaUJ+lyn2iZtHywK104+kw4iMIdAL0ctR+gQjf1N8adJQ5D/4Dp36Czs9L2dJX+owpFhjq6tiN+B0iqZiKRBbSEa08dCAkWGu64NMxE7NB9ATFPbb1qg7NFr8zzzpOYK3OnJhRwLidxCYEU5UZ5bFzIfepETQ6HJbY8a6iakaxUgU4d+dOTuvx1AI0w/VILIobYB7KHL/I0yFP4Se54tbuJadmkRzVyKodxscT5xo+BJv5mTXRnVAfDu15KaedHjogf7OaLmzaPzpLqig1bYSA9ps365v92ke3SJ7enNzSvW4RdrHqiK2w8LnGSIdoDdyn85oBufgkrvSUR0KGI7DjTfxVwJ8Ae2Tk5f+zpH/5d7R98iOOZyNntrWE8CTgwe3WrTOnsRL/F9oOr0cg7Qqs9JeREO46TFcgtQp8iZKlEjuR9vSuueDPcnB7qAO19qDZhDkPV/J+KoXbFNFLFCk2JqDJ/rZmwEB6N9cGBeId6xt1n0kMZbFljzkG46L8YP3feG3akcFLsWsC3OF0Mb+bE795aX/S/uO3N+kTJJaAbcTHV6KFSBq83YyQFT5vmbbHPHAehaxXeLlf7GnlZiHSeim3cLyOTNbjZxy40c45KbpVCh6cHQJTyWYIEk7r0wC1VuMlKHLBttJnaWVUIyxzsCJvt0a9Mh1+ozkMHPpNiadIj1ozKCSIidrzqYgOohkJhQ9bfciS Rfo3U+28 acuGNPlWUiqOUgPNPhIZYrIeo5Q7CEfyAcxlo1yF2CNPOGkgUzpt83WXkDD+7cPzeQfNU7mzY2yTHHpiLsrakOwGJ/x0q7lUfVcw94dM34QkyrE8jhFx3Df4U2AAePws4FrAyXmRDtEVFv1JWAPc1/iTEfkamID0VOiwhcsMygTwqj94HLFC9hB3WGHxg1WrBlgLlnj69Eaf8O2ygrekGR9RrMCHTHqQgRhFsMJPXz1dC2A1wXNAsBG8CQZcqjcR0VZHVTjhPYQPfj2WU24B8rBJjxgkO6pQTrBm4rKsuPW01cf8wBOwyJjzNlaT5d6mJq9vOqjfF2YTyb+dWvfYACbSCkAnT3TD2MCEBrragr+o0wFx9Q2TcI51Ih08eSUCioyGMOg6TCVWxqklvBi0D7fmWj2pkJYUUh1JH 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, Jan 10, 2024 at 4:35=E2=80=AFPM Matthew Wilcox wrote: > > On Wed, Jan 10, 2024 at 05:28:22PM +0200, Joonas Lahtinen wrote: > > Quoting Joonas Lahtinen (2024-01-10 17:20:24) > > > However we specifically pass "huge=3Dwithin_size" to vfs_kern_mount w= hen > > > creating a private mount of tmpfs for the purpose of i915 created > > > allocations. > > > > > > Older hardware also had some address hashing bugs where 2M aligned > > > memory caused a lot of collisions in TLB so we don't enable it always= . > > > > > > You can see drivers/gpu/drm/i915/gem/i915_gemfs.c function > > > i915_gemfs_init for details and references. > > > > > > So in short, functionality wise we should be fine either default > > > for using 2M pages or not. If they become the default, we'd probably > > > want an option that would still be able to prevent them for performan= ce > > > regression reasons on older hardware. > > > > To maybe write out my concern better: > > > > Is there plan to enable huge pages by default in shmem? > > Not in the next kernel release, but eventually the plan is to allow > arbitrary order folios to be used in shmem. So you could ask it to creat= e > a 256kB folio for you, if that's the right size to manage memory in. > > How shmem and its various users go about choosing the right size is not > quite clear to me yet. Perhaps somebody else will do it before I get > to it; I have a lot of different sub-projects to work on at the moment, > and shmem isn't blocking any of them. And I have a sneaking suspicion > that more work is needed in the swap code to deal with arbitrary order > folios, so that's another reason for me to delay looking at this ;-) I have sent large folios support for shmem for the write and fallocate path some releases ago. The main problem I was facing was a current upstream problem with huge pages when seeking holes/data (fstests generic/285 and generic/436). The strategy suggested was to use large folios in an opportunistic way based on the file size. This hit the same problem we currently have with huge pages and I considered that a regression. We have made some progress to fix seeking in huge pages upstream but is not yet finished. I can send the patches tomorrow for further discussion. >