Thread (55 messages) 55 messages, 3 authors, 2019-08-12

Re: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder

From: Brendan Higgins <hidden>
Date: 2019-07-15 22:43:37
Also in: dri-devel, linux-devicetree, linux-fsdevel, linux-kbuild, linux-kselftest, linux-um, lkml, nvdimm

On Mon, Jul 15, 2019 at 3:11 PM Brendan Higgins
[off-list ref] wrote:
On Mon, Jul 15, 2019 at 3:04 PM Stephen Boyd [off-list ref] wrote:
quoted
Quoting Brendan Higgins (2019-07-15 14:11:50)
quoted
On Mon, Jul 15, 2019 at 1:43 PM Stephen Boyd [off-list ref] wrote:
quoted
I also wonder if it would be better to just have a big slop buffer of a
4K page or something so that we almost never have to allocate anything
with a string_stream and we can just rely on a reader consuming data
while writers are writing. That might work out better, but I don't quite
understand the use case for the string stream.
That makes sense, but might that also waste memory since we will
almost never need that much memory?
Why do we care? These are unit tests.
Agreed.
quoted
Having allocations in here makes
things more complicated, whereas it would be simpler to have a pointer
and a spinlock operating on a chunk of memory that gets flushed out
periodically.
I am not so sure. I have to have the logic to allocate memory in some
case no matter what (what if I need more memory that my preallocated
chuck?). I think it is simpler to always request an allocation than to
only sometimes request an allocation.
Another even simpler alternative might be to just allocate memory
using kunit_kmalloc as we need it and just let the kunit_resource code
handle cleaning it all up when the test case finishes.

What do you think?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help