On 3/20/22 06:13, Hyeonggon Yoo wrote: >> While this is no longer a problem in kmemcg context thanks to the accounting >> rewrite in 5.9, the memory waste is still not ideal and it's questionable >> whether it makes sense to perform free object count based control when object >> counts can easily become so much inaccurate. So this patch converts the >> accounting to be based on number of pages only (which is precise) and removes >> the page->pobjects field completely. This is also ultimately simpler. >> >> To retain the existing set_cpu_partial() heuristic, first calculate the target >> number of objects as previously, but then convert it to target number of pages >> by assuming the pages will be half-filled on average. This assumption might >> obviously also be inaccurate in practice, but cannot degrade to actual number of >> pages being equal to the target number of objects. > > I have to agree that this half-filled assumption works pretty well and > I believe the too-long-partial-list problem has gone. we're controlling > its length clearly after this patch. > > But my one concern here is that actual number of objects in > percpu partial list can be decreased when we cannot allocate high order pages. > > e.g.) oo_order(s->oo) is 3 and we can only allocate order-2 page, > it can be shortened 2 times in worst case because the accounting logic > assumes order of all slab in the percpu partial list is oo_order(s->oo). That's true, but let's not forget the percpu partial lists are motivated by peak performance in e.g. networking. Once we start having issues allocating e.g. order-2 pages due to fragmentation, the system is probably far from peak performance already, so this pessimism in slub partial lists is not the main concern. > I think using object based accounting, and assuming every slab is > half-filled would be more consistent when the system is highly > fragmented. Based on reasoning above, I doubt it's worth the trouble. Thanks. > Thoughts? >
