Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4438945pxu; Mon, 21 Dec 2020 12:30:55 -0800 (PST) X-Google-Smtp-Source: ABdhPJxSEj7TXMSZGiR5Eg951ou9i1Gbi2wkGK/cwsfrs2HrRqehMJWE9P+KZCykJvPwqPPc9oKe X-Received: by 2002:a17:907:429d:: with SMTP id ny21mr16924641ejb.290.1608582655454; Mon, 21 Dec 2020 12:30:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608582655; cv=none; d=google.com; s=arc-20160816; b=MpXGjwCNkqrSSMPQleob/L2bhCUm0eJ0O+9byc03s5dLZsgALkQf09UypTma3huOXo QrSjfGdBC5S68jMihZ8apJqgiouryt9kaZITkxyCDv/r34XGbzUl3Ljt6JIrawcfbIjv L2FGHUlxBD+7WYBSBZCwjhUtNPD7nEPXOYw+mUqM6kZElsLRaTYVjtoVzGCucfHIB4JH mpVY9K1XfY2NO5A2twcJr0sOkPiRl2Eu/JHUrbvwvKY8+9pao+UJDKwS08qcpo92RWhG Rok+tbTJmdyU5xBWtBCnDt8Gdl2ZTiD/9pMb1lw9ra5xpnj9NRW0GsGuqNW8acJIa2sd ED1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=jxLW2pdUWD7RzC62LfDYxo1HOe4nc7nIXlrDQklPFuU=; b=OeKeFxK1YE/8ARIt+kzZQQI+EQaw6mY0vKhhDbeM/WyzeleQYpFOuuGDY9U0NEt4EV /zEYa3ftWXRfDvjG92POUsoNjXqS+aOCqlDep0J0qhEuPBBlMcPmIAvEoU0ee3iJgEKc BiEEV6SGoNYthyRnkiH7aQTqwgu+Zn9Ks7p1zYELS01uM8nLssca6C03RiKaWB7g+9uP R72LmBPgzkY6nZ/RXdExvTcvzOSdcUuu5vXrMzQr9K7xkJoyDBtS1ARGlpN3Wr5p0EnP MbPB+ZWJjURG7lRKoQ+j8Ywp2G2k4mPDzfDzWE7iybJ6JHbGQd5vnMS6IuhOlNo0q0nG FTIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QcYIhsyz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q4si10468724eji.447.2020.12.21.12.30.31; Mon, 21 Dec 2020 12:30:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=QcYIhsyz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725949AbgLUU36 (ORCPT + 99 others); Mon, 21 Dec 2020 15:29:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725785AbgLUU36 (ORCPT ); Mon, 21 Dec 2020 15:29:58 -0500 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D1021C0613D3 for ; Mon, 21 Dec 2020 12:29:17 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id j1so6209782pld.3 for ; Mon, 21 Dec 2020 12:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jxLW2pdUWD7RzC62LfDYxo1HOe4nc7nIXlrDQklPFuU=; b=QcYIhsyzsT3cpFBxIQogxXeiwDgF4ahvIkqsoOOddsOKu1aXJtWZXhvWZTSFoRvOtq Y2+9LQi704NiDZmu6QWZ/6BzvFlgI8UcW+dJgOtO/ZL0uhEjXN5JiNBv1dMvaWD3chy9 ZiZym9rjs7H717mshEohmqV5V3VMAvaQAcQ4z4BUr5gX+yUSM9xdbkX0anjqgqf5mjaw tz3j4hQBworRUgE0dCli4Oz9QOirl7LG8W0xlU7hfCYatPFvuH5vRac34qH7g/mYm+Jl KHmkN6Gl3eWFCsJVDpsah5C6VzuESn/5hLotj6Qlx/s3NzCvXdVgUCWmTXHkf0jxHEnu +siQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=jxLW2pdUWD7RzC62LfDYxo1HOe4nc7nIXlrDQklPFuU=; b=WaF+0otNcvjN/QrJs13JqkgxeZoF5+Sxk4Pm6XzxIyHSZEaNOOqBtwwcf2Fuvp27oF hgca/SFpxLkTghh8I+Y8DtYNlEjSRTBshR4uTI4KzJB2jVEsLj6Uk6rcphyxGB+8C2zM bGsfiAOuivHenBPfdzAH34gtq72B5smXN4OOQbPXkF7wf/DivhJkWuqkhffUaftkiaCE NMdadGo6A3j+t6ewMah75ynhsC5hDsiDdqS8Je6fAw7+DYuSzHeKAazgAnQvZay6xV19 kL2NV7O3p0YTiNCfNdr3/B9C9CXMPLHxGtdeyCDBnQx3Malu5THLXxHEOHc2U60UBKq8 SpoA== X-Gm-Message-State: AOAM531dEitIyesKjEvtktrZ7vGr8L7mTi3rqUBFUwWp6kntn5hIKpaw mXs/vTaSmu2OMIWg3or4Lus= X-Received: by 2002:a17:90a:b110:: with SMTP id z16mr18441668pjq.167.1608582556811; Mon, 21 Dec 2020 12:29:16 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id f29sm17695810pfk.32.2020.12.21.12.29.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Dec 2020 12:29:15 -0800 (PST) Sender: Minchan Kim Date: Mon, 21 Dec 2020 12:29:13 -0800 From: Minchan Kim To: Alexander Potapenko Cc: Vijayanand Jitta , Vincenzo Frascino , dan.j.williams@intel.com, broonie@kernel.org, Masami Hiramatsu , LKML , Andrew Morton , Andrey Konovalov , qcai@redhat.com, ylal@codeaurora.org, vinmenon@codeaurora.org, kasan-dev Subject: Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE Message-ID: References: <7f2e171f-fa44-ef96-6cc6-14e615e3e457@codeaurora.org> <601d4b1a-8526-f7ad-d0f3-305894682109@codeaurora.org> <9e0d2c07-af1f-a1d3-fb0d-dbf2ae669f96@codeaurora.org> <48df48fe-dc36-83a4-1c11-e9d0cf230372@codeaurora.org> <6110a26b-dc87-b6f9-e679-aa60917403de@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 21, 2020 at 04:04:09PM +0100, Alexander Potapenko wrote: > On Mon, Dec 21, 2020 at 12:15 PM Vijayanand Jitta wrote: > > > > > > > > On 12/18/2020 2:10 PM, Vijayanand Jitta wrote: > > > > > > > > > On 12/17/2020 4:24 PM, Alexander Potapenko wrote: > > >>>> Can you provide an example of a use case in which the user wants to > > >>>> use the stack depot of a smaller size without disabling it completely, > > >>>> and that size cannot be configured statically? > > >>>> As far as I understand, for the page owner example you gave it's > > >>>> sufficient to provide a switch that can disable the stack depot if > > >>>> page_owner=off. > > >>>> > > >>> There are two use cases here, > > >>> > > >>> 1. We don't want to consume memory when page_owner=off ,boolean flag > > >>> would work here. > > >>> > > >>> 2. We would want to enable page_owner on low ram devices but we don't > > >>> want stack depot to consume 8 MB of memory, so for this case we would > > >>> need a configurable stack_hash_size so that we can still use page_owner > > >>> with lower memory consumption. > > >>> > > >>> So, a configurable stack_hash_size would work for both these use cases, > > >>> we can set it to '0' for first case and set the required size for the > > >>> second case. > > >> > > >> Will a combined solution with a boolean boot-time flag and a static > > >> CONFIG_STACKDEPOT_HASH_SIZE work for these cases? > > >> I suppose low-memory devices have a separate kernel config anyway? > > >> > > > > > > Yes, the combined solution will also work but i think having a single > > > run time config is simpler instead of having two things to configure. > > > > > > > To add to it we started of with a CONFIG first, after the comments from > > Minchan (https://lkml.org/lkml/2020/11/3/2121) we decided to switch to > > run time param. > > > > Quoting Minchan's comments below: > > > > " > > 1. When we don't use page_owner, we don't want to waste any memory for > > stackdepot hash array. > > 2. When we use page_owner, we want to have reasonable stackdeport hash array > > > > With this configuration, it couldn't meet since we always need to > > reserve a reasonable size for the array. > > Can't we make the hash size as a kernel parameter? > > With it, we could use it like this. > > > > 1. page_owner=off, stackdepot_stack_hash=0 -> no more wasted memory > > when we don't use page_owner > > 2. page_owner=on, stackdepot_stack_hash=8M -> reasonable hash size > > when we use page_owner. > > " > > Minchan, what do you think about making the hash size itself a static > parameter, while letting the user disable stackdepot completely at > runtime? > As noted before, I am concerned that moving a low-level configuration > bit (which essentially means "save 8Mb - (1 << stackdepot_stack_hash) > of static memory") to the boot parameters will be unused by most > admins and may actually trick them into thinking they reduce the > overall stackdepot memory consumption noticeably. > I also suppose device vendors may prefer setting a fixed (maybe > non-default) hash size for low-memory devices rather than letting the > admins increase it. I am totally fine if we could save the static memory alloation when the page_owner is not used. IOW, page_owner=disable, stackdepot=disable will not consume the 8M memory. When we want to use page_owner, we could just do like this page_owner=enable, stackdepot=enable (Maybe we need something to make warning if stackdepot is disabled but someone want to use it, for example, KASAN?) Vijayanand, If we could work this this, should we still need the config option, then?