On Thu 2019-03-28 16:12:28, Steven Rostedt wrote:
On Thu, 28 Mar 2019 12:45:18 -0700 Doug Anderson dianders@chromium.org wrote:
I see solution is simple, but now we have a loop with GFP_ATOMIC allocations inside. How many "tracing spus" is this expected to loop over? Will not it exhaust atomically available pages and reliably fail in common configurations? Pavel
Each one of these allocations is ~32 bytes and you do one per CPU. Even with systems with a lot of CPUs that's not going to be tons. ...and you only do it with GFP_ATOMIC when you're actively dropped into kdb and debugging. It seems like going for simplicity is the right call here, but of course if Steven or Daniel say that it has to be done a different way then they're the true authorities.
I really don't care. The code in question is only affected when we have CONFIG_KGDB_KDB enabled. But as it gets called from an atomic context, is it any different than what it was doing before? Except now with GFP_ATOMIC it is actually safer.
Now, we could add some helper functions in the ring-buffer code to allow us to pre-allocate the ring_buffer_iter at boot up. Then we could pass in the per-allocated iters and use them here.
Ok, I guess 32 bytes is small enough, I somehow imagined it would be bigger...