On Mon, Aug 17, 2020 at 10:28:49AM +0200, Michal Hocko wrote: > On Mon 17-08-20 00:56:55, Uladzislau Rezki wrote: [ . . . ] > > wget ftp://vps418301.ovh.net/incoming/1000000_kmalloc_kfree_rcu_proc_percpu_pagelist_fractio_is_8.png > > 1/8 of the memory in pcp lists is quite large and likely not something > used very often. > > Both these numbers just make me think that a dedicated pool of page > pre-allocated for RCU specifically might be a better solution. I still > haven't read through that branch of the email thread though so there > might be some pretty convincing argments to not do that. To avoid the problematic corner cases, we would need way more dedicated memory than is reasonable, as in well over one hundred pages per CPU. Sure, we could choose a smaller number, but then we are failing to defend against flooding, even on systems that have more than enough free memory to be able to do so. It would be better to live within what is available, taking the performance/robustness hit only if there isn't enough. My current belief is that we need a combination of (1) either the GFP_NOLOCK flag or Peter Zijlstra's patch and (2) Thomas Gleixner's delayed allocation approach. As you say and as Uladislau's measurements suggest, if we only have Peter's approach, although we could handle short floods just fine, we could not handle longer-term floods. And Thomas's approach is in fact designed to handle these longer-term floods. Except that if we have only Thomas's approach, then we have to handle the possibility that RCU_SOFTIRQ happened on the back of an interrupt that happened while the interrupted process was holding a memory-allocator lock. This means further deferral, such as going into a workqueue, which would allow better memory-allocator results, but which would also mean further delays from the time that memory was needed until the time that it was actually supplied. Delays that could be bridged by either a GFP_NOLOCK flag or Peter's patch. So again, it looks like this is not an either/or situation, but rather an need-both situation. I freely confess that one of my hopes almost 30 years ago was that a high-quality parallel memory allocator would eliminate the need for special-purpose allocators, but as has been noted several times on this thread, reality does not always seem to be compelled to take such hopes into account. Thanx, Paul
