Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3342205iog; Mon, 20 Jun 2022 17:49:03 -0700 (PDT) X-Google-Smtp-Source: AGRyM1twHN451ZM1tthHYLn73b9kotcwuyfus/i8W/U6Bj710fxTT32xeR6N8ND+N1tMvp+piBZU X-Received: by 2002:a17:907:6ea4:b0:711:d106:b93a with SMTP id sh36-20020a1709076ea400b00711d106b93amr23621055ejc.189.1655772542900; Mon, 20 Jun 2022 17:49:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655772542; cv=none; d=google.com; s=arc-20160816; b=F/t8u2Yd5glKeVZMxCf10YezP5T76MkjZcAo3JyXo6DmkokisNCjemt3wTQQSxvxdZ WVNTDHVqVFsdPEtBUDUrma0iXN83SrAUBqS+RKls8gO2oN4MfwN1JUm3HGHMK5psxCh0 w3WdN80vdy59NU1JeBi5FxQ4VMhYiQvJIdreEkWzUrk4ogl2JaF85yaB7yumE0j2sERH QpPQneONnRyRDgbVsEZcyn1nlXPQZjmoFuvkTmyVSpvibO2Izjcj19YK9R3KmeEKkJkV PzBeeXjbJgkmrwUiqa53bzex2iAKKut5KuGwycA3F+ofSYlHnc5uj8ckmdDOXdwQ50Fu A79A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id; bh=3agRZ6Mg0AYPykWFdIRrPIifwfLvHugO2Lix+Sz8SQ4=; b=bIKAwciwpe1UEvE9RGNdpCZL34kTNMbDT2SrlK+VmC+xgrQzH20MvoP747hFkU2FeA WjEHd+xoqBQB/4QMY2/QIwGx81FzOLMXjz3ll2F19lHh8Q7NlAAMrQiBW9iJSY66MxxY p3ccAW2o68TUTwzmJhDbv3a/VMRAYz+oscE+b3qwvJq4RuV2Xy4lDyBkw2NA8MtQ9jOZ jiWM8qUso0lxvy0haDygzSO9YHKwMKYE72hpatp/YWx6UuQ7IzWnZ3fps4pJE6Wlpi94 UQGsSm371Vzq2UGZKTFahG4SM1Pr2+ML55/1JV+wa1O3+0cI+/R9gqOHHEUTN+IlU+gg EY2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b14-20020aa7cd0e000000b004357523b6a3si7349981edw.550.2022.06.20.17.48.38; Mon, 20 Jun 2022 17:49:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242245AbiFUAi6 convert rfc822-to-8bit (ORCPT + 99 others); Mon, 20 Jun 2022 20:38:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235324AbiFUAi5 (ORCPT ); Mon, 20 Jun 2022 20:38:57 -0400 Received: from relay3.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2A61510FE8 for ; Mon, 20 Jun 2022 17:38:56 -0700 (PDT) Received: from omf02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B538D20FDD; Tue, 21 Jun 2022 00:38:53 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: joe@perches.com) by omf02.hostedemail.com (Postfix) with ESMTPA id 254A08000A; Tue, 21 Jun 2022 00:38:52 +0000 (UTC) Message-ID: <53d77ae6101a0f24cfb694174d4c7699424c57e8.camel@perches.com> Subject: Re: [PATCH v4 00/34] Printbufs - new data structure for building strings From: Joe Perches To: Kent Overstreet , David Laight Cc: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "pmladek@suse.com" , "rostedt@goodmis.org" , "enozhatsky@chromium.org" , "linux@rasmusvillemoes.dk" , "willy@infradead.org" Date: Mon, 20 Jun 2022 17:38:51 -0700 In-Reply-To: <20220620150514.3tjy5dv7pv5frcwd@moria.home.lan> References: <20220620004233.3805-1-kent.overstreet@gmail.com> <0a5901f8460f452a89c9b0cda32fb833@AcuMS.aculab.com> <20220620150514.3tjy5dv7pv5frcwd@moria.home.lan> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.44.1-0ubuntu1 MIME-Version: 1.0 X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_SPF_HELO, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Stat-Signature: 4q1qktg797qyt7kwq1opekn7fu3or1wu X-Rspamd-Server: rspamout06 X-Rspamd-Queue-Id: 254A08000A X-Session-Marker: 6A6F6540706572636865732E636F6D X-Session-ID: U2FsdGVkX18iuMOlb5rJsZQ4wQ5Qfk4CeiXDod72ZqY= X-HE-Tag: 1655771932-377534 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2022-06-20 at 11:07 -0400, Kent Overstreet wrote: > On Mon, Jun 20, 2022 at 04:19:31AM +0000, David Laight wrote: > > I really think that is a bad idea. > > printk() already uses a lot of stack, anything doing a recursive > > call is just making that worse. > > Especially since these calls can often be in error paths > > which are not often tested and can already be on deep stacks. > > We went over this before - this patch series drastically reduces stack usage of > sprintf by eliminating a bunch of stack allocated buffers. Do try to keep up... I generally agree with David. I think Kent has not provided data that this actually _reduces_ stack usage. Converting stack variables to call stack frames does not necessarily reduce overall stack usage when the stack frame plus any locally used stack in the called function is added together.