From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hnPSq-0003bs-Vy for linux-um@lists.infradead.org; Tue, 16 Jul 2019 15:34:02 +0000 MIME-Version: 1.0 In-Reply-To: References: <20190712081744.87097-1-brendanhiggins@google.com> <20190712081744.87097-4-brendanhiggins@google.com> <20190715204356.4E3F92145D@mail.kernel.org> <20190715220407.0030420665@mail.kernel.org> From: Stephen Boyd Subject: Re: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder Date: Tue, 16 Jul 2019 08:33:59 -0700 Message-Id: <20190716153400.5CB182054F@mail.kernel.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Brendan Higgins Cc: Petr Mladek , "open list:DOCUMENTATION" , Peter Zijlstra , Amir Goldstein , dri-devel , Sasha Levin , Masahiro Yamada , Michael Ellerman , "open list:KERNEL SELFTEST FRAMEWORK" , shuah , Rob Herring , linux-nvdimm , Frank Rowand , Knut Omang , Kieran Bingham , wfg@linux.intel.com, Joel Stanley , David Rientjes , Jeff Dike , Dan Carpenter , devicetree , linux-kbuild , "Bird, Timothy , linux-um@lists.infradead.org, Steven Rostedt" , Julia Lawall , Josh Poimboeuf , kunit-dev@googlegroups.com, Theodore Ts'o , Richard Weinberger , Greg KH , Randy Dunlap , Linux Kernel Mailing List , Luis Chamberlain , Daniel Vetter , Kees Cook , linux-fsdevel@vger.kernel.org, Logan Gunthorpe , Kevin Hilman Quoting Brendan Higgins (2019-07-15 15:43:20) > On Mon, Jul 15, 2019 at 3:11 PM Brendan Higgins > wrote: > > > > On Mon, Jul 15, 2019 at 3:04 PM Stephen Boyd wrote: > > > > > > Quoting Brendan Higgins (2019-07-15 14:11:50) > > > > On Mon, Jul 15, 2019 at 1:43 PM Stephen Boyd 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. > > 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? _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um