On 05.10.23 21:23, Yu Zhao wrote:
On Thu, Oct 5, 2023 at 2:12 AM David Hildenbrand <david@xxxxxxxxxx> wrote:
On 29.09.23 21:08, Andrew Morton wrote:
The patch titled
Subject: mm: non-pmd-mappable, large folios for folio_add_new_anon_rmap()
has been added to the -mm mm-unstable branch. Its filename is
mm-non-pmd-mappable-large-folios-for-folio_add_new_anon_rmap.patch
Andrew, please don't move these patches to stable before we have a
couple of acks from people involved in the discussions.
I'm confident that we'll get them into 6.8.
I am not :)
Well, there is still quite some time for 6.8, not so much for 6.7 :)
Even if we end up with something minimal.
But I'm afraid (and previously expressed) a pure kconfig won't be
sufficient, at least not for distributions.
I did not look into the details of the latest proposal, unfortunately,
but I'll spoiler that exposing orders and bitmaps to users is not what I
would immediately classify as a nice interface :)
Anyhow, let's not get distracted ...
As I repeated, the priorities seem wrong to me. There are many pending
work items that don't involve any ABI changes, and IMO, we should
focus on them before we even start discussing ABI changes.
I tend to agree: part of me being slower on feedback to the latest
series is that I rather spent time trying to sort out some of the
pending work items -- well, one, to be precise, which is challenging enough.
That's also one of the reason I don't see a need to rush this in: it
would be in a state where no distribution could consider enabling it. So
as a distribution guy, I don't see that much value in that ;)
One could certainly say that some of the pending items are not relevant
for this to get merged and used to some degree. But again, from a
distribution aspect, I think some of the pending items are a *requirement*.
I've been quiet because I don't think opinion based discussions are
essential to nailing down ABIs. As I suggested, I prefer a Kconfig
Please don't be quiet.
option as the first step so that people can play with it. After we
have collected field data, then we'd be better at coming up with
suitable ABIs.
As I expressed, for me a magical toggle to enable/disable it (and if
enabled, obey the existing THP rules) would be good enough for the first
shot. It won't be sufficient for some workloads we discussed in the
meetings, though.
So I see how Ryan tried to find something that is more configurable.
Ideally, we'd probably have something that easily lets one enable a sane
default (which we can tweak as we go), but still let people that want to
configure it, just configure it. IMHO, nothing wrong with that. I might
have some ideas, but again, lower priority for me at this point.
--
Cheers,
David / dhildenb
