From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B6B13E0259 for ; Wed, 13 May 2026 08:51:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.21 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778662292; cv=none; b=g2Bk1cAmryWvV95ftvcWihZbX9VNlQscaR2WAqsNNXRNnzVzACLbB1aOronz9+JA6lh+hBI3QyByjgXuiRWpeRGvQC7azjrdCooROijGI1EiCNw18w3yxDAunxJA/ywyaBoxPxy+NoWCJEEG8/baqqSBsPZsfylbBDnaRrdKD6I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778662292; c=relaxed/simple; bh=Gb6cdQvgIjVHP6q1cmpqeNRXvuWiP2WWdB4XYzroKVA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=fgCQebC5TOhUQn6nC4Seo3E+pvUgGXgeFjzKDQZiY2NTRssfKXKXpRc47VsAoo4bFc5h3JJTq45hjlI7EzfZWyVmYEjeKSDc/1IMDJmYBybecMJPDEp9ZOT7qr2V8035GB5kz/dnxlwU8bB8r7m27UYOtoQMiknwOIFc1YXc8bc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=lJP070Cl; arc=none smtp.client-ip=198.175.65.21 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="lJP070Cl" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778662290; x=1810198290; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=Gb6cdQvgIjVHP6q1cmpqeNRXvuWiP2WWdB4XYzroKVA=; b=lJP070ClFHv3Bff0hiN9rjQF/4SbWIAK2vZdj764pq2TZp7Jt2Lt4DWg oVnASCtbfqxxhFNfCavV2T/alLeo8gDq4RSyn+umYTMMRieUBaNTmjskZ V+0Eg7lPOBCJjcVYGDUJ9f7q2vU7FJyY8DYL14sz/irVPOz1g0pHAF8dv lYjhzVhCzCsJ+Ol1Z2h9oNRrkcGtWghO09JBBYUJDgAA7sirSJsObDDWJ MtScwWuNNPmi6WJeb1UJy4vRl49Ht8GYZF0iJYnEITKERPFpQ3L/zYjB5 tZWDwPcsHARHQOGDrUZg5/tpAu24j1ksLiNNkga9MusVLZCNJOkjgJy7v g==; X-CSE-ConnectionGUID: 4ZGRErZaQsS2wWuUIjz6nA== X-CSE-MsgGUID: SUDSa1lNRryN7eJwV2GRvw== X-IronPort-AV: E=McAfee;i="6800,10657,11784"; a="79478905" X-IronPort-AV: E=Sophos;i="6.23,232,1770624000"; d="scan'208";a="79478905" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa113.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2026 01:51:30 -0700 X-CSE-ConnectionGUID: lxKHFfy8S8yGC7CiOwCOCw== X-CSE-MsgGUID: hT7mcpayQQ+0Z7a3TAKHHg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,232,1770624000"; d="scan'208";a="261767495" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO [10.245.244.49]) ([10.245.244.49]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2026 01:51:24 -0700 Message-ID: <1ce447ceea88bbe56c7d28654a51fc2856a7f986.camel@linux.intel.com> Subject: Re: [PATCH 1/2] mm/shmem: add shmem_insert_folio() From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: "David Hildenbrand (Arm)" , Christian =?ISO-8859-1?Q?K=F6nig?= , intel-xe@lists.freedesktop.org Cc: Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Hugh Dickins , Baolin Wang , Brendan Jackman , Johannes Weiner , Zi Yan , Huang Rui , Matthew Auld , Matthew Brost , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Wed, 13 May 2026 10:51:21 +0200 In-Reply-To: References: <20260512110339.6244-1-thomas.hellstrom@linux.intel.com> <20260512110339.6244-2-thomas.hellstrom@linux.intel.com> <26479389-459b-4cc4-914d-e7d29d5e5cc9@kernel.org> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-05-13 at 10:37 +0200, David Hildenbrand (Arm) wrote: > On 5/13/26 09:47, Christian K=C3=B6nig wrote: > > Hi David & Thomas, > >=20 > > On 5/12/26 22:03, David Hildenbrand (Arm) wrote: > > > On 5/12/26 13:31, Thomas Hellstr=C3=B6m wrote: > > ... > > > >=20 > > > > OK, can eliminate those. Is VM_WARN_ON_FOLIO() preferred, > > > > or any other type of assert? > > >=20 > > > VM_WARN_ON_FOLIO() is usually what you want, or > > > VM_WARN_ON_ONCE(). > > >=20 > > > >=20 > > > >=20 > > > > OK, let me understand the concern. The pages are allocated as > > > > multi- > > > > page folios using alloc_pages(gfp, order), but typically not > > > > promoted > > > > to compound pages, until inserted here. Is it that promotion > > > > that is of > > > > concern or inserting pages of unknown origin into shmem? > > > > Anything we > > > > can do to alleviate that concern? > > >=20 > > > It's all rather questionable. > > >=20 > > > A couple of points: > > >=20 > > > a) The pages are allocated to be unmovable, but adding them to > > > shmem effectively > > > =C2=A0=C2=A0 turns them movable. Now you interfere with the page allo= cator > > > logic of > > > =C2=A0=C2=A0 placing movable and unmovable pages a reasonable way int= o > > > =C2=A0=C2=A0 pageblocks that group allocations of similar types. > > >=20 > > > b) A driver is not supposed to decide which folio size will be > > > allocated for > > > =C2=A0=C2=A0 shmem. > >=20 > > Exactly that is one of the major reasons why we aren't using a > > shmem as backing store for TTM buffers in the first place. >=20 > What was the problem with that the last time this was considered? >=20 > shmem nowadays supports THP (e.g., 2M) and even mTHP (e.g., 64K). >=20 > For internal mounts, it must be enabled accordingly > (/sys/kernel/mm/transparent_hugepage/.../shmem_enabled). >=20 > Some distributions still default to "never". I guess if an admin > enables it, you > would just get THPs. FWIW, the i915 driver which uses shmem "natively" uses a special mount here that gives back THPs. >=20 > If "distro default" is the only problem, I guess we could think about > how to > improve that. For example, just let internal GPU DRM objects allocate > any folio > size available and supported etc. >=20 > Would that make it possible to just use shmem natively? (e.g., how > would this > interact with shmem features like folio migration, would that be > workable with > DRM objects?). Currently the drivers that use shmem in this way use "mapping_set_unevictable()" as long as the object is bound to the GPU. Then shrinkers can unbind from GPU and revert that setting. The problem, (as also stated in the cover letter of this series) is for drivers that need to change caching of the pages to WC or UC. That's an extremely costly operation so TTM needs to pool such allocations. That's where using shmem natively becomes very ugly, because you can't really use a 1:1 mapping between shmem objects and DRM objects anymore. Thanks, Thomas