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 67940C4725D for ; Wed, 10 Jan 2024 15:20:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C619F6B007B; Wed, 10 Jan 2024 10:20:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C10FE6B0096; Wed, 10 Jan 2024 10:20:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD8C46B0098; Wed, 10 Jan 2024 10:20:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 98F836B007B for ; Wed, 10 Jan 2024 10:20:41 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 50283C0AE3 for ; Wed, 10 Jan 2024 15:20:41 +0000 (UTC) X-FDA: 81663763482.27.4CC83B4 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.88]) by imf22.hostedemail.com (Postfix) with ESMTP id B93AAC001E for ; Wed, 10 Jan 2024 15:20:38 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=bT7ADZPa; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of joonas.lahtinen@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=joonas.lahtinen@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704900039; 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=LY//HiHtHMDfxw08XiTOK4kydpcIqQwogsNuWE6j6pg=; b=2aR500ZVzsqJWicBoU7aNilKigwZcBRkZK/u0vXe4TVUG0hsHxxVwqlgHsKQF3LTmh2yax IRbCR6SgmZAIzl+N5tDiQvRRpq6lEmycVz2/yFIveBIhgW4x8FFQzr8jva7H/iBElp+xK4 mpFKNZ8bskRCK+YpcUhjZYrflJdoYVY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=bT7ADZPa; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of joonas.lahtinen@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=joonas.lahtinen@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704900039; a=rsa-sha256; cv=none; b=Khehwq+Hq35g0ez+J7E4dj1buCiOjZRBFTu4WOg78CAyT5y6KXHNQByrEsaUv98DidM5ly kkb1JYxSDwJXTIfvMtv6EwvzPzlSxTHMTaHKj6j5mD9vZA3wTTPU7DnmlycbnDalclb7Fo GZ016moDrm3ngHWXAc0xgAyacPFpB1I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1704900038; x=1736436038; h=mime-version:content-transfer-encoding:in-reply-to: references:subject:to:cc:from:message-id:date; bh=E0Bmp/5XWFLDuolIr/rqLJ0YwdpFYqvUjJulwkaWkOU=; b=bT7ADZPaTyX3nidKP+KiD4JIG/eUACsWnzNpUxvLqMS07Tll5l8PU5/q I2wuRrgCxzm6+bh4GOw7YRqqkVXkBHohyGdl9KecdpgqM9PupkiwP5dD1 XPpyIQMvuWzTVAku9K9BCejguLVLrV2IV1rH3msAjRim+dJCKpRN5ZUyw feFx7YBQv5S+/J2u7CK7B3NnZEAaxne1be31kL2T9AjVta60UBwsw/Iac +tfkjoCM9nfXWbmZluHaGN7RQLoN1+Dokl2QTBW+e/tnw0KMYRHxifTHh i7szbeUtE/VRZ1s/ZTohWMFNOvJUN+kRNmhvR/zi5K0Onv7qOOpMwhMAE A==; X-IronPort-AV: E=McAfee;i="6600,9927,10948"; a="429731682" X-IronPort-AV: E=Sophos;i="6.04,184,1695711600"; d="scan'208";a="429731682" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2024 07:20:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10948"; a="905573417" X-IronPort-AV: E=Sophos;i="6.04,184,1695711600"; d="scan'208";a="905573417" Received: from nselinsk-mobl.ger.corp.intel.com (HELO localhost) ([10.246.34.242]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jan 2024 07:20:28 -0800 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20240110092109.1950011-1-hch@lst.de> Subject: Re: disable large folios for shmem file used by xfs xfile To: Christoph Hellwig , Matthew Wilcox Cc: 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 From: Joonas Lahtinen Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Message-ID: <170490002493.164187.5401160425746227111@jlahtine-mobl.ger.corp.intel.com> User-Agent: alot/0.8.1 Date: Wed, 10 Jan 2024 17:20:24 +0200 X-Rspam-User: X-Stat-Signature: e1agbn8g4m9yfyse8ss3nk8mf8axw6ti X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B93AAC001E X-HE-Tag: 1704900038-969303 X-HE-Meta: U2FsdGVkX1/mupaU3SnJcpNmyCrMFBSsSVAYdh2fynVYNf7uTXbcshtXgsKVMuzw3hTveCsBG5zf5g957+ZS3ZdraEZNGMeyuZzNks0Mtd1t8+2CowKoGXrV0MakkatcbZf7rBa09soO9z6h7mjDBqy9m1pyoIvxEam7pEkxd03dMdnpnFP8q3u7M0I3Gpy4ANCkLL0Y+rrEDHmLLii2QgkL5MgDGKMyZ9bdHik539Ahm+1hfCEYwZ/3eATo53J9Fg5pd07JGNcxPeVOYQnMIKgZ1tqUO9qjzX5AWbcqOt0Oe0PTOXxqZf3lYHYED8WyuT2ucucEmbdr/KbaW1Z+uC0x6XvPTtVouhSiA7axQjWH5wtTVZcrohIJJFKQVxf/FU6hrQ+EHsfJhlHYJhCkelNvYkoK5aE/vT2IqMaHFcsf9ymd1fZ5/5IiK+L3Inrk18sI4cNuUEFUFCUdoRPuiWzkyfg/b3vuy9GoPKt/kbXGT/SRxj6ei1466n5xHBtN2rlhgszH7Ipx/6Eqz3dehOlsKuXuubFHq90sShPL5mXVGTaAMSQOBK3JeMeHL8DUolbtv8FRktSKAO+KWVjCCluvI+ZyFtsoGAPJ+yMxR+ElvGvr0RIYOJ8nq9o0Vv8Yc0BvH/vSsnWWUpHIKcOLmqLlsjlznbVFRRPiLUNhByzApcrSHeGOcf4fJLQ9C5Dv1CU+0GQelyteXJrcHo0+C9uSIf6Hem1GSdcwTvcyG2CyC9UoGlPao5M+E0aKHTKWWr06GIDKRwGNopv++LkbBxPH4UHw7+vymsAskn6uxEgv8x8t1PyRkPR5CZoX/bbPwfVU2Yudqsc9gYlAAkWPQCUYq/9KquyiSmutdQoDqb/Xx8c/LX20qkZ6AJ6DE8n3unKheMJBtT8/wpPGfJAVAlInzvIg/e2SD7udZpDrGmap31yxdG3HBZMasXklp7uTl5Wy9jmdsfcSwoKlpfX rDaESmfH +Wsmn+BYZpXQ3BvbPj9/oKDShw8ej0nmfzseJqGT6Cy6ApJVD0e7NyIyFp5H22xd2+w45qlsUX1oId+W1zfszmYQ9gmnhLrgMF+bOFRpSdR8vufQDgeqg28gCDV0aOLyK5D4boCZVnXiiPH4QTtBNTdqnnB/BhYerwEhPpTyPEhqeJQQ= 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: Quoting Matthew Wilcox (2024-01-10 14:37:18) > On Wed, Jan 10, 2024 at 10:21:07AM +0100, Christoph Hellwig wrote: > > Hi all, > >=20 > > Darrick reported that the fairly new XFS xfile code blows up when force > > enabling large folio for shmem. This series fixes this quickly by disa= bling > > large folios for this particular shmem file for now until it can be fix= ed > > properly, which will be a lot more invasive. > >=20 > > I've added most of you to the CC list as I suspect most other users of > > shmem_file_setup and friends will have similar issues. >=20 > The graphics users _want_ to use large folios. I'm pretty sure they've > been tested with this. Correct. We've done quite a bit of optimization in userspace and enabling in kernel to take advantage of page sizes of 2M and beyond. However we specifically pass "huge=3Dwithin_size" to vfs_kern_mount when 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 performance regression reasons on older hardware. Regards, Joonas > It's just XFS that didn't know about this > feature of shmem.