lkml.org 
[lkml]   [2019]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder
    On Tue, Jul 16, 2019 at 8:34 AM Stephen Boyd <sboyd@kernel.org> wrote:
    >
    > Quoting Brendan Higgins (2019-07-15 15:43:20)
    > > On Mon, Jul 15, 2019 at 3:11 PM Brendan Higgins
    > > <brendanhiggins@google.com> wrote:
    > > >
    > > > On Mon, Jul 15, 2019 at 3:04 PM Stephen Boyd <sboyd@kernel.org> wrote:
    > > > >
    > > > > Quoting Brendan Higgins (2019-07-15 14:11:50)
    > > > > > On Mon, Jul 15, 2019 at 1:43 PM Stephen Boyd <sboyd@kernel.org> wrote:
    > > > > > >
    > > > > > > 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.
    > > >
    > > > > 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.
    >
    > Sure, sounds like a nice way to avoid duplicating similar logic to
    > maintain a list of things to free later.

    I think I will go that route for now.

    > >
    > > What do you think?
    >
    > If you go the allocation route then you'll need to have the flags to
    > know what context you're in to allocate appropriately. Does that mean
    > all the string operations will now take GFP flags?

    We could set the GFP flags in the constructor, store them in a field,
    and then just reuse them.

    Thanks!

    \
     
     \ /
      Last update: 2019-07-16 20:56    [W:4.901 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site