> On Thu 13-08-20 19:09:29, Thomas Gleixner wrote: > > Michal Hocko <mhocko@xxxxxxxx> writes: > [...] > > > Why should we limit the functionality of the allocator for something > > > that is not a real problem? > > > > We'd limit the allocator for exactly ONE new user which was aware of > > this problem _before_ the code hit mainline. And that ONE user is > > prepared to handle the fail. > > If we are to limit the functionality to this one particular user then > I would consider a dedicated gfp flag a huge overkill. It would be much > more easier to have a preallocated pool of pages and use those and > completely avoid the core allocator. That would certainly only shift the > complexity to the caller but if it is expected there would be only that > single user then it would be probably better than opening a can of worms > like allocator usable from raw spin locks. > Vlastimil raised same question earlier, i answered, but let me answer again: It is hard to achieve because the logic does not stick to certain static test case, i.e. it depends on how heavily kfree_rcu(single/double) are used. Based on that, "how heavily" - number of pages are formed, until the drain/reclaimer thread frees them. Preloading pages and keeping them for internal use, IMHO, seems not optimal from the point of resources wasting. It is better to have a fast mechanism to request a page and release it back for needs of others. As described about we do not know how much we will need. -- Vlad Rezki
