On Tue, 3 Apr 2018 18:11:19 +0200 Michal Hocko <mhocko@xxxxxxxxxx> wrote: > You can do so, of course. In fact it would have some advantages over > single pages because you would fragment the memory less but this is not > a reliable prevention from OOM killing and the complete memory > depletion if you allow arbitrary trace buffer sizes. You are right that this doesn't prevent OOM killing. I tried various methods, and the only thing that currently "works" the way I'm happy with, is this original patch. >From your earlier email: > Except that it doesn't work. si_mem_available is not really suitable for > any allocation estimations. Its only purpose is to provide a very rough > estimation for userspace. Any other use is basically abuse. The > situation can change really quickly. Really it is really hard to be > clever here with the volatility the memory allocations can cause. Now can you please explain to me why si_mem_available is not suitable for my purpose. If it's wrong and states there is less memory than actually exists, we simply fail to increase the buffer. If it is wrong and states that there is more memory than actually exists, then we do nothing different than what we do today, and trigger an OOM. But for the ring buffer use case, it is "good enough". Can you please explain to me what issues you see that can happen if we apply this patch? -- Steve
