From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D744242D7B for ; Fri, 14 Nov 2025 08:02:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763107356; cv=none; b=UzxuzeFP5KoXB1UawTEWK2ew37sdTvCzhn5W681Vou4ol4uQMzbHsNDfmZazw5mulwn0IrYAinRlHR7Q9O8Qbvd1jAb9IYrmXhYWpiOzutrI9ta1v9Nlr9kRzxaatzIxhhWNfy2GN1Qx1KA+FTcOFz7fCyKKb2RuysUcPCE9bfM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763107356; c=relaxed/simple; bh=q8JCjR/+cWiO8moBZuKjwiKifE6a99Si/caoEQiL8mQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sNz18D3JfeLwxeqtk25jvEgEb1O+8ZpU8d7RLaeEHQpLiPHN/V/voJkTFhAWRDb72nWpEh5RudriIfDQ4ROCVx1k+ryGyiiqTOHf1TyGSkf9RBRAVEqyLT8rO+ydqwYJe9HeoXdX1AVqI2IeZNlztlIVSpq+kqFteut9ZuuIfBw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=CT2LbgF5; arc=none smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="CT2LbgF5" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-640aa1445c3so2727379a12.1 for ; Fri, 14 Nov 2025 00:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763107353; x=1763712153; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=4KbiNU5yCfEN4FXal09etJPtHEak6Phh1dFiA4B8zJk=; b=CT2LbgF5z/VSvYPc+UupAAqRvR0k61v4KaQiRMSnABxAFLHeE1rTP8IGN8KPMr1NKQ 8q79nxF/E+afyTz386oH6Pn3sznUrsD0PyiOoo/XeX+avGMvIHqCo+nk6fao8vTu2Z26 ijvo3onjsyrAXR3cZwKDe4B2YKDHxi5m8dTSc65/blfLTZ/WceOz6mXZiIRSLwd/wqVR o6GZVn5kDciVzU7NXEjUkv7eM6JnLd508TeZsaSEZu1j0h4ehoOPTo2IG8LrrTdCR+6/ woJw/3JmtCutd3PpqDa57NBq9lCsYr9yXJg1AME4FEcwER6/WNwlT3/MPT33Vx7V4idG sK6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763107353; x=1763712153; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4KbiNU5yCfEN4FXal09etJPtHEak6Phh1dFiA4B8zJk=; b=Y04vLQwUEc1SeoKWVVOd5kNQf8NlXiGcsdku/RXtT21Lbbych862Wo5NtBT7nz6ihd xhArnzzt4HaFkUmatnNMP3u4yIa/Jc3Bo0LDJ8/POXN4eTA6JQ+qOxuuenyhS44Wvao3 MH1nXedpql1e1G42NRm4KyyiXtp8ZnuWFkPMSnLgqzuxecBETUtAFHlfysaXWeiVGLF9 1wRTPW1J5hjj9LJ6Zp8HWce9T5MxUNXMx54KepZr3g3X0CqFQBqyqsXdROSPQP+vYd8p HqUKT2uH3vRjlIGBg0jcngB+GrDgtNRUVu6gbtTbttoVYvdarikekupiCIu8q/Ubmzj/ n+aQ== X-Forwarded-Encrypted: i=1; AJvYcCUB3KtbUpuuXuezlDSjS+afSIH9ZZR6Sdb1omB9HyW2s/7BaaIIyoGOgobjRZnExbzyFW9cKkhu3AO8+aY=@vger.kernel.org X-Gm-Message-State: AOJu0YyUmomrxPbjGl+w/op+5zBMJjKggfmIcsKQFg6IJFYLAbBdd0sL ml8aaUh9CwQp5OfLIfm8B4VPipBKqx6jANAoU3hcm81ytpBJk2ymK91R X-Gm-Gg: ASbGncs+Mexqtxpn/8n8em9pTTNPdJvce0WFAMhFAMRFDiLv1xsJiEaYg97jLF/HbYV 8UrgSIbFbmQ5sX0NS3z/Fbg3emCigwMnrQ8C3v7h9KouVijct0aMzfzWr0NPYCF0VmDJ/tw4to1 AwjjITrCbU1ANYvbfPEDp2vtMK8zeAnrn/2RfGXsBjrw2bQmQhdobNXCjJGd/xzA8j2b6JM6CTS oSd7qih26eTyFJnkFfkinfEgqSZ0rrFcl4cbtjz+otFF83+wkx52P9g8Jl0i9gN5biAeWoQZj0N gdxnTU2hkWvcEyLdRZIATwEni/aZkrUrSHB5dX98DXoOfnzDXNQC9QuzaOQx/SERWtEj+/CHdgA TGwcA79V5Ozl2vfYOgo26vyR0/uXFzTS57/II7+vQQ7Iur8PO/UjSAOhcj2GUk3T7zBuAkgD4AF zqt5WxQD7zHjiL7w== X-Google-Smtp-Source: AGHT+IFHp4R0zTwE4dMochE8kl4UmvqdsH7ba7lQ82B8UAtO+/J0teWF71l9ELhwzjeYKUxsrmiq1w== X-Received: by 2002:a05:6402:3592:b0:640:7529:b8d3 with SMTP id 4fb4d7f45d1cf-64350e2321amr1683582a12.9.1763107353191; Fri, 14 Nov 2025 00:02:33 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6433a2d746bsm3123759a12.0.2025.11.14.00.02.32 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Nov 2025 00:02:32 -0800 (PST) Date: Fri, 14 Nov 2025 08:02:32 +0000 From: Wei Yang To: Balbir Singh Cc: Wei Yang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org, Andrew Morton , David Hildenbrand , Zi Yan , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Oscar Salvador , Lorenzo Stoakes , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lyude Paul , Danilo Krummrich , David Airlie , Simona Vetter , Ralph Campbell , Mika =?iso-8859-1?Q?Penttil=E4?= , Matthew Brost , Francois Dugast Subject: Re: [PATCH] mm/huge_memory.c: introduce folio_split_unmapped Message-ID: <20251114080232.kxms4vjlkiiuxqpl@master> Reply-To: Wei Yang References: <20251114012228.2634882-1-balbirs@nvidia.com> <20251114032105.sdkjaoiwpdmpynew@master> <870151ce-ca90-4cd4-8f21-35f4da329924@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <870151ce-ca90-4cd4-8f21-35f4da329924@nvidia.com> User-Agent: NeoMutt/20170113 (1.7.2) On Fri, Nov 14, 2025 at 02:30:03PM +1100, Balbir Singh wrote: >On 11/14/25 14:21, Wei Yang wrote: >> On Fri, Nov 14, 2025 at 12:22:28PM +1100, Balbir Singh wrote: >> [...] >>> @@ -4079,6 +4091,36 @@ static int __folio_split(struct folio *folio, unsigned int new_order, >>> return ret; >>> } >>> >>> +/* >>> + * This function is a helper for splitting folios that have already been unmapped. >>> + * The use case is that the device or the CPU can refuse to migrate THP pages in >>> + * the middle of migration, due to allocation issues on either side >>> + * >>> + * The high level code is copied from __folio_split, since the pages are anonymous >>> + * and are already isolated from the LRU, the code has been simplified to not >>> + * burden __folio_split with unmapped sprinkled into the code. >>> + * >>> + * None of the split folios are unlocked >>> + */ >>> +int folio_split_unmapped(struct folio *folio, unsigned int new_order) >>> +{ >>> + int extra_pins, ret = 0; >>> + >>> + VM_WARN_ON_FOLIO(folio_mapped(folio), folio); >>> + VM_WARN_ON_ONCE_FOLIO(!folio_test_locked(folio), folio); >>> + VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio); >>> + >> >> Compared with original logic, we did check folio_split_supported() and >> check whether new_order is supported for the file system. >> >> Currently folio_split_unmapped() only pass 0 as new_order, which looks good. >> But for a generic helper, it looks reasonable to do the check, IMHO. >> > >This is meant to be used in the middle of a migration where the src/dst do >no agree on the folio_order() due to allocation issues. When mTHP support >is added to device migration, order support will be added and checked. >FYI: This routines supports just anonymous pages ATM > OK, I don't see these assumptions. Not sure it would be abused. Maybe a comment would help? Or remove the new_order now? We can add it when it is truly used. >>> + if (!can_split_folio(folio, 1, &extra_pins)) >>> + return -EAGAIN; >>> + >>> + local_irq_disable(); >>> + ret = __folio_freeze_and_split_unmapped(folio, new_order, &folio->page, NULL, >>> + NULL, false, NULL, SPLIT_TYPE_UNIFORM, >>> + 0, extra_pins); >>> + local_irq_enable(); >>> + return ret; >>> +} >>> + >>> /* >>> * This function splits a large folio into smaller folios of order @new_order. >>> * @page can point to any page of the large folio to split. The split operation >> >> > >Balbir -- Wei Yang Help you, Help me