On Wed, Oct 13, 2021 at 10:16 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > [...] > > > If this is really that complicated (I haven't tried) then it would be > > > much more simple to completely skip the bulk allocator for __GFP_ACCOUNT > > > rather than add a tricky code. The bulk allocator is meant to be used > > > for ultra hot paths and memcg charging along with the reclaim doesn't > > > really fit into that model anyway. Or are there any actual users who > > > really need bulk allocator optimization and also need memcg accounting? > > > > Bulk allocator is being used for vmalloc and we have several > > kvmalloc() with __GFP_ACCOUNT allocations. > > Do we really need to use bulk allocator for these allocations? > Bulk allocator is an bypass of the page allocator for performance reason > and I can see why that can be useful but considering that the charging > path can imply some heavy lifting is all the code churn to make bulk > allocator memcg aware really worth it? Why cannot we simply skip over > bulk allocator for __GFP_ACCOUNT. That would be a trivial fix. > -- Actually that might be the simplest solution and I agree to skip bulk allocator for __GFP_ACCOUNT allocations.
