Re: [PATCH v3 11/18] mm/huge_memory: allow splitting mappingless swap cache folios

["David Hildenbrand (Arm)" <david@kernel.org>]

On 8/27/26 21:16, David Hildenbrand (Arm) wrote:
> On 8/27/26 19:41, Kairui Song wrote:
>> On Fri, Aug 28, 2026 at 12:41 AM David Hildenbrand (Arm)
>> <david@kernel.org> wrote:
>>>
>>> These two boolean parameters are really a pain. There must be a better way.
>>>
>>> Also, I don't like that __folio_split_unmap_and_freeze() sounds generic again.
>>>
>>> There must be a better way for that as well. We had a clean split and now we
>>> mangle it again.
>>>
>>>
>>> ... but I am just before my PTO and out of puff, so others can brainstorm on how
>>> to do this cleaner :)
>>
>> What if we just keep the __folio_split_unmap_and_freeze_anon name? And
>> have that "bool remap" mentioned in previous reply? Clean swap cache
> 
> I think you can just rely on folio_mapped() internally. swapcache-only is never
> mapped. And anon folios you can just detect internally as well, right?
> 
>> could be considered "anon compatible" as they might become anon
> 
> Dirty but better than what you have right now. As you say, there really is no
> difference.
> 
> But for example the mapping/remapping is superfluous. So you could also consider
> a _swapcache that reuses some common bits from the _anon helper.
> 

Okay, I took another look at the resulting __folio_split() and I think if you
pack the "Unlock all after-split folios" into a separate helper function, and
call this helper from inside the _anon / _file etc, you can just end up with
very nice function names:

	ret = folio_check_splittable(folio, new_order, split_type);
	...

	if (is_anon)
		ret = __folio_split_anon(...);
	else if (is_swapcache)
		ret = __folio_split_swapcache(...)
	else
		ret = __folio_split_file(...)

out:
	if (is_pmd_order(old_order))
		...
	return ret;

IOW, the common bits don't have to be called by __folio_split(), but can be
called by the other helpers.


I guess it would be ok to have something like

__folio_split_anon_or_swapcache(...);

(the function name length is acceptable)

-- 
Cheers,

David