On Sun, Aug 4, 2024 at 7:33 PM Rik van Riel <riel@xxxxxxxxxxx> wrote: > > On Sun, 2024-08-04 at 15:54 -0600, Yu Zhao wrote: > > On Thu, Aug 1, 2024 at 9:47 AM David Hildenbrand <david@xxxxxxxxxx> > > wrote: > > > > > > On 01.08.24 08:09, Yu Zhao wrote: > > > > > > > > I would recommend shatter [1] instead of splitting so that > > > > 1) whoever underutilized their THPs get punished for the > > > > overhead; > > > > 2) underutilized THPs are kept intact and can be reused by > > > > others. > > > > > > > > [1] > > > > https://lore.kernel.org/20240229183436.4110845-3-yuzhao@xxxxxxxxxx/ > > > > > > > > > > Do you have any plans to upstream the shattering also during > > > "ordinary" > > > deferred splitting? > > > > Yes, once we finish verifying it in our production. > > > > Shattering does seem like a nice improvement to the THP shrinker! > > However, given that the shattering code is still being verified, > and the THP shrinker policy will no doubt need some tuning once > more real world workloads get thrown at it, would it make sense > to do those two things in parallel? > > We could move forward with the THP shrinker as-is today, and use > the increased exposure it gets to fine tune the shrinking policy, > and then move it over to using the shattering code once that is > ready. > > Is there any good reason to serialize these two things? I'm fine with whichever way you prefer: if you are eager to try shattering in your production environment, I'd be incentivized to throw in extra engineers and get it ready for you asap.
