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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71F43C43334 for ; Mon, 20 Jun 2022 12:00:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BF118E0001; Mon, 20 Jun 2022 08:00:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 047636B0074; Mon, 20 Jun 2022 08:00:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E02638E0001; Mon, 20 Jun 2022 08:00:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id CA2CC6B0071 for ; Mon, 20 Jun 2022 08:00:44 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 88F4B120CF6 for ; Mon, 20 Jun 2022 12:00:44 +0000 (UTC) X-FDA: 79598472408.15.C373703 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf26.hostedemail.com (Postfix) with ESMTP id BC1531400BA for ; Mon, 20 Jun 2022 12:00:42 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3ABC121AD3; Mon, 20 Jun 2022 12:00:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1655726441; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6rWFG3uWKuuKdwZT86iOp2RBtyzj8xN/EPYd8WQXuuY=; b=0QbMavM04QGJH3Y/IhTNDgFjE/11rLYDqeBfol2PSI9ZR4ZUTRF3bLUXOX1aRW+Cgh4CEQ rz6nTSkEi9Kkbcs8K7h8BRHqINwOJSazZl0IFJQgPQr5QK4kglrMAyh4eTGpHFhVhzUj/p cL2ohjotxpZtyFKE5rnGYCN/zxKfz3k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1655726441; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6rWFG3uWKuuKdwZT86iOp2RBtyzj8xN/EPYd8WQXuuY=; b=wK1upZ9g1hWwLkkhiY1nwMk+CxWTKKbDOs1po/GRfj6PtiirYM4Z85HNmbaEUAnj+hD2fD MrO9j9H3bfl9g9CA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 1AC13134CA; Mon, 20 Jun 2022 12:00:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 4ZbUBWlhsGLaEwAAMHmgww (envelope-from ); Mon, 20 Jun 2022 12:00:41 +0000 Message-ID: <93bf8148-ecc1-75fb-423b-2a76c7252c4e@suse.cz> Date: Mon, 20 Jun 2022 14:00:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [RFC PATCH 1/1] lib/stackdepot: replace CONFIG_STACK_HASH_ORDER with automatic sizing Content-Language: en-US To: Dmitry Vyukov Cc: Marco Elver , Alexander Potapenko , Linus Torvalds , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrey Konovalov , kasan-dev@googlegroups.com References: <20220527113706.24870-1-vbabka@suse.cz> <20220527113706.24870-2-vbabka@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655726443; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6rWFG3uWKuuKdwZT86iOp2RBtyzj8xN/EPYd8WQXuuY=; b=2TyExBTP1STxomn/HO4MhclliCciMI+S/1NP9wXzPPW7cHu8GKiNTnd1fSg7hAMHmKksAp CW343+1VdpmNSru0H9LV/dCCx0fgTD3X28qLzF06SMIfLirjsYG6r/LDdvfJMulJVp8Ius 2yTgpN8qtiUPzHI1RlXu7LHj1Vph7Uc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=0QbMavM0; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wK1upZ9g; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655726443; a=rsa-sha256; cv=none; b=kmaNMIuZWB+TsfsJqiYjYSvCYs7UZIQsr1Z8yhWtOfLXA7XEi/jkfflpkkgwWr/O7bj0vM Ui6OePidbuUcxZCESFZBxTVp3HBIzRQckF+hDH06rFP3ACNcXzrIWtcH40AdtwC/1DBm3X svVWSSABAeBb9K0Yp2f689Hf+p1GGTw= X-Stat-Signature: q4phs4g7mjkc4jxaqc1mt5kdfwpsnatx X-Rspamd-Queue-Id: BC1531400BA X-Rspamd-Server: rspam11 X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=0QbMavM0; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wK1upZ9g; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-HE-Tag: 1655726442-693367 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 5/27/22 14:02, Dmitry Vyukov wrote: > On Fri, 27 May 2022 at 13:37, Vlastimil Babka wrote: >> >> As Linus explained [1], setting the stackdepot hash table size as a >> config option is suboptimal, especially as stackdepot becomes a >> dependency of less specialized subsystems than initially (e.g. DRM, >> networking, SLUB_DEBUG): >> >> : (a) it introduces a new compile-time question that isn't sane to ask >> : a regular user, but is now exposed to regular users. >> >> : (b) this by default uses 1MB of memory for a feature that didn't in >> : the past, so now if you have small machines you need to make sure you >> : make a special kernel config for them. >> >> Ideally we would employ rhashtable for fully automatic resizing, which >> should be feasible for many of the new users, but problematic for the >> original users with restricted context that call __stack_depot_save() >> with can_alloc == false, i.e. KASAN. >> >> However we can easily remove the config option and scale the hash table >> automatically with system memory. The STACK_HASH_MASK constant becomes >> stack_hash_mask variable and is used only in one mask operation, so the >> overhead should be negligible to none. For early allocation we can >> employ the existing alloc_large_system_hash() function and perform >> similar scaling for the late allocation. >> >> The existing limits of the config option (between 4k and 1M buckets) >> are preserved, and scaling factor is set to one bucket per 16kB memory >> so on 64bit the max 1M buckets (8MB memory) is achieved with 16GB >> system, while a 1GB system will use 512kB. > > Hi Vlastimil, > > We use KASAN with VMs with 2GB of memory. > If I did the math correctly this will result in 128K entries, while > currently we have CONFIG_STACK_HASH_ORDER=20 even for arm32. > I am actually not sure how full the table gets, but we can fuzz a > large kernel for up to an hour, so we can get lots of stacks (we were > the only known users who routinely overflowed default LOCKDEP tables > :)). Aha, good to know the order of 20 has some real use case then :) > I am not opposed to this in general. And I understand that KASAN Is > different from the other users. > What do you think re allowing CONFIG_STACK_HASH_ORDER=0/is not set > which will mean auto-size, but keeping ability to set exact size as > well? > Or alternatively auto-size if KASAN is not enabled and use a large > table otherwise? But I am not sure if anybody used > CONFIG_STACK_HASH_ORDER to reduce the default size with KASAN... Well if you're unsure and nobody else requested it so far, we could try setting it to 20 when KASAN is enabled, and autosize otherwise. If somebody comes up with a use-case for the boot-time parameter override (instead of CONFIG_), we can add it then? >> If needed, the automatic scaling could be complemented with a boot-time >> kernel parameter, but it feels pointless to add it without a specific >> use case.