On Mon, Sep 21, 2020 at 09:47:16AM +0200, Michal Hocko wrote: > On Fri 18-09-20 21:48:15, Uladzislau Rezki (Sony) wrote: > [...] > > Proposal > > ======== > > Introduce a lock-free function that obtain a page from the per-cpu-lists > > on current CPU. It returns NULL rather than acquiring any non-raw spinlock. > > I was not happy about this solution when we have discussed this > last time and I have to say I am still not happy. This is exposing > an internal allocator optimization and allows a hard to estimate > consumption of pcp free pages. IIUC this run on pcp cache can be > controled directly from userspace (close(open) loop IIRC) which makes it > even bigger no-no. Yes, I do well remember that you are unhappy with this approach. Unfortunately, thus far, there is no solution that makes all developers happy. You might be glad to hear that we are also looking into other solutions, each of which makes some other developers unhappy. So we are at least not picking on you alone. :-/ > I strongly agree with Thomas http://lkml.kernel.org/r/87tux4kefm.fsf@xxxxxxxxxxxxxxxxxxxxxxx > that this optimization is not aiming at reasonable workloads. Really, go > with pre-allocated buffer and fallback to whatever slow path you have > already. Exposing more internals of the allocator is not going to do any > good for long term maintainability. I suggest that you carefully re-read the thread following that email. Given a choice between making users unhappy and making developers unhappy, I will side with the users each and every time. Thanx, Paul
