From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B2A49C7618F for ; Tue, 16 Jul 2019 15:34:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 84F2420880 for ; Tue, 16 Jul 2019 15:34:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563291243; bh=V4ev/UU39RHvFkNjkPsY3SOAdIqI9PBECtJV0Q6gb5E=; h=In-Reply-To:References:From:To:Cc:Subject:Date:List-ID:From; b=Dwjam0HHTRy3kfRsp1Lme38qYBfRmMkxlkUJKcUz8V9t7+mEh4+BWbA1XY67dLsQT Xf40lVqMeuqvdYgE/MLgfQuFdX65wqPBFNf8fAR48JRqYDlpiWmjSLncN5uGo/Oded sB+yBJJJKno2e6TTBhJyo8MmjIuifhHp9eIg1MGg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387971AbfGPPeC (ORCPT ); Tue, 16 Jul 2019 11:34:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:37558 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725926AbfGPPeB (ORCPT ); Tue, 16 Jul 2019 11:34:01 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5CB182054F; Tue, 16 Jul 2019 15:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563291240; bh=V4ev/UU39RHvFkNjkPsY3SOAdIqI9PBECtJV0Q6gb5E=; h=In-Reply-To:References:From:To:Cc:Subject:Date:From; b=OI5X53OX1byrP6tlrUCjRpeJ1oQOTnBd5OqI0zkPlySCP8J7YdSPWzyzurB0yXcW5 tojB8NLHwRsWz19d2LLzm7R0Y/GV+eoAx6B2iENKbOicQFlEaTQrErT0xo7BH5fqoh gpLKApR/IyGssgFicaQIy6L8qsIKeBP/gh0ZNKpo= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 To: Brendan Higgins Cc: Frank Rowand , Greg KH , Josh Poimboeuf , Kees Cook , Kieran Bingham , Luis Chamberlain , Peter Zijlstra , Rob Herring , shuah , Theodore Ts'o , Masahiro Yamada , devicetree , dri-devel , kunit-dev@googlegroups.com, "open list:DOCUMENTATION" , linux-fsdevel@vger.kernel.org, linux-kbuild , Linux Kernel Mailing List , "open list:KERNEL SELFTEST FRAMEWORK" , linux-nvdimm , linux-um@lists.infradead.org, Sasha Levin , "Bird, Timothy" , Amir Goldstein , Dan Carpenter , Daniel Vetter , Jeff Dike , Joel Stanley , Julia Lawall , Kevin Hilman , Knut Omang , Logan Gunthorpe , Michael Ellerman , Petr Mladek , Randy Dunlap , Richard Weinberger , David Rientjes , Steven Rostedt , wfg@linux.intel.com Subject: Re: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder User-Agent: alot/0.8.1 Date: Tue, 16 Jul 2019 08:33:59 -0700 Message-Id: <20190716153400.5CB182054F@mail.kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 wro= te: > > > > > > > > > > I also wonder if it would be better to just have a big slop buffe= r of a > > > > > 4K page or something so that we almost never have to allocate any= thing > > > > > with a string_stream and we can just rely on a reader consuming d= ata > > > > > 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. >=20 > 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. >=20 > 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?