On 5/13/24 7:33 PM, Linus Torvalds wrote: > On Thu, 9 May 2024 at 07:25, Vlastimil Babka <vbabka@xxxxxxx> wrote: >> >> To avoid affecting fast paths with another shared counter (attempted in the >> past) or complex partial list traversal schemes that allow rescheduling, the >> chosen solution resorts to approximation - when the partial list is over >> 10000 slabs long, we will only traverse first 5000 slabs from head and tail >> each and use the average of those to estimate the whole list. Both head and >> tail are used as the slabs near head to tend to have more free objects than >> the slabs towards the tail. > > I suspect you could have cut this down by an order of magnitude, and > made the limit be just 1k slabs rather than 10k slabs. Or even > _another_ order of magnitude smaller. > > Somebody was being a bit too worried about approximations, methinks - Indeed, my focus was that we make the approximation as accurate as possible when introducing it, to minimize the chance of possibly breaking somebody and having to revert it. Then we can try reduce the limit once the approach itself is established. > but I think the real worry goes the other way, where it's practically > so hard to even hit the approximation situation that it gets no > testing at all. Good point. > IOW, I suspect it's better to be explicit about approximations, and > have people aware of it, rather than be overly cautious and have it be > a special case that almost never triggers in any normal loads. OK we can reduce the limit sooner than later. As for explicit, there was an idea that an approximated line in slabinfo would be marked, but I thought changing the layout would be more likely to break someone parsing it, than an unmarked approximation. We can be more explicit e.g. in the documentation though for sure. > But pulled. Thanks. > > Linus
