From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id D899A7D90F for ; Mon, 15 Jul 2019 22:04:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731590AbfGOWEI (ORCPT ); Mon, 15 Jul 2019 18:04:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:33906 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730647AbfGOWEI (ORCPT ); Mon, 15 Jul 2019 18:04:08 -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 0030420665; Mon, 15 Jul 2019 22:04:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563228247; bh=lzmzGxC84ycn5YPcgrlTTZCsaQHNzr70lnAMErLcD6E=; h=In-Reply-To:References:From:To:Subject:Cc:Date:From; b=yjILvyTeOyRdWTjel54BWNGgZ1ntKYib3gQKxCNMZGijJY1OIFiN5Q/Cq5W/Sq65r OjyZGX9OeeT3oFA8a4sDcYrXowZlMFMynYaGOGbEAJsQkEWD3FqBmHRAOOmQwn1vSW sbrWnUD7cVteQcJnCcGYDIxrhTqiEX8IEogTyyrs= 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> From: Stephen Boyd To: Brendan Higgins Subject: Re: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder 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 User-Agent: alot/0.8.1 Date: Mon, 15 Jul 2019 15:04:06 -0700 Message-Id: <20190715220407.0030420665@mail.kernel.org> Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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. >=20 > 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. 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B7A1321962301 for ; Mon, 15 Jul 2019 15:06:35 -0700 (PDT) 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> From: Stephen Boyd Subject: Re: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder Date: Mon, 15 Jul 2019 15:04:06 -0700 Message-Id: <20190715220407.0030420665@mail.kernel.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" 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, Kevin Hilman List-ID: 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. 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. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm 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 1hn94p-0004tF-M6 for linux-um@lists.infradead.org; Mon, 15 Jul 2019 22:04:08 +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> From: Stephen Boyd Subject: Re: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder Date: Mon, 15 Jul 2019 15:04:06 -0700 Message-Id: <20190715220407.0030420665@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 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. 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. _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH v9 03/18] kunit: test: add string_stream a std::stream like string builder Date: Mon, 15 Jul 2019 15:04:06 -0700 Message-ID: <20190715220407.0030420665@mail.kernel.org> References: <20190712081744.87097-1-brendanhiggins@google.com> <20190712081744.87097-4-brendanhiggins@google.com> <20190715204356.4E3F92145D@mail.kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org 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 List-Id: devicetree@vger.kernel.org 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. >=20 > 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. 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.