Printbuf rebuffed for now [LWN.net]

Printbuf rebuffed for now

Posted Apr 28, 2022 19:42 UTC (Thu) by mb (subscriber, #50428)
Parent article: Printbuf rebuffed for now

Dynamic memory allocation seems to be a bit of an overkill for such a feature. Usually users would have a rough estimate about how much buffer space will be needed. It can then often be cheaply allocated on the stack.

On the other hand, the seq_buf boilerplate (two variables and seq_buf_init) seems a bit verbose.
That should be combined into a macro for an easy to use on-stack use case.

to post comments

Printbuf rebuffed for now

Posted Apr 29, 2022 1:40 UTC (Fri) by nevets (subscriber, #11875) [Link] (8 responses)

There's limited stack space in the kernel. One needs to be very careful of stack usage otherwise you'll crash the kernel.

Printbuf rebuffed for now

Posted Apr 29, 2022 3:10 UTC (Fri) by Paf (subscriber, #91811) [Link] (3 responses)

And there’s no way to know at runtime if you have any to spare. You’ll just crash the thing. So, caution is required with any stack allocation of meaningful size.

Printbuf rebuffed for now

Posted Apr 29, 2022 6:31 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

>And there’s no way to know at runtime if you have any to spare.

If you have a fixed stack size with known begin and end pointers, then you'd just have to subtract SP from the end pointer.

Buf of course, what would you do then? Print an error message? ;)

Printbuf rebuffed for now

Posted Apr 29, 2022 10:00 UTC (Fri) by matthias (subscriber, #94967) [Link]

This only works, if you either do not do any method call or you know for sure how much stack space the invoked methods will use in the worst case.

Printbuf rebuffed for now

Posted Apr 29, 2022 13:20 UTC (Fri) by nevets (subscriber, #11875) [Link]

> If you have a fixed stack size with known begin and end pointers, then you'd just have to subtract SP from the end pointer.

It's even more complex than that. Depending on the architecture, if you are in interrupt context, you may be on a different stack that is even a different size than the normal context stack. This would require an architecture dependent implementation.

Printbuf rebuffed for now

Posted Apr 29, 2022 6:26 UTC (Fri) by mb (subscriber, #50428) [Link]

Yeah, well. For the usual log messages you need 100? 200? bytes of temporary memory.
And if you need more, then it would probably be a good idea to have dynamic allocation as a second option or use a static allocation.

Just saying that I doubt dynamic allocation is a good trade off for the majority of use cases.

(And wasn't there work on getting a dynamic kernel stack? I'm not sure what state that is in.)

Printbuf rebuffed for now

Posted Apr 29, 2022 7:34 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

On the other hand statically guessing a required size will probably end up wasting more memory in the vast majority of the cases that do not use the peak amount of memory used in that code-path for all the code-paths where the length of the message varies significantly.

Printbuf rebuffed for now

Posted Apr 29, 2022 13:35 UTC (Fri) by ldearquer (guest, #137451) [Link] (1 responses)

Maybe it is not too bad if you constraint your guess to the OOM management code paths. The rest of the code can still allocate dynamically.

Printbuf rebuffed for now

Posted May 5, 2022 10:58 UTC (Thu) by smoogen (subscriber, #97) [Link]

Is it possible to have an 'early' set aside amount of memory, and then try to allocate more if needed and if it fails send a 'truncated' set of the output in the set-aside memory? That way if you run out you can still print something as a fall back? [And from this the try_alloc() call was written.. where we try to allocate but if its not there, meh.]