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 ED3F2C636D6 for ; Wed, 8 Feb 2023 20:46:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 068196B0071; Wed, 8 Feb 2023 15:46:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 018F36B0072; Wed, 8 Feb 2023 15:46:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFAE16B0074; Wed, 8 Feb 2023 15:46:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CBA386B0071 for ; Wed, 8 Feb 2023 15:46:36 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8E632120880 for ; Wed, 8 Feb 2023 20:46:36 +0000 (UTC) X-FDA: 80445307992.19.598AECF Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf28.hostedemail.com (Postfix) with ESMTP id B79CFC001A for ; Wed, 8 Feb 2023 20:46:33 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=x0L7KZHk; dkim=pass header.d=linutronix.de header.s=2020e header.b=8746gtP2; spf=pass (imf28.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675889194; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=55HBVmJdWZuIgrtPK8UZxNppgqRsonQ+DQObFnSi/4I=; b=5pjb/ksK9Us6XTV8YIHJkegudhNmeU5HY7BB+KP9/rzxykPCj1H23cY2f8v+vY41dEw1QO Rx7zlA8QAxSjbuWXiU7pgb0OC4ZyGGs9r5JBNXUCMyC1pjlubGh7+umwcKEFG0nvBWLr9w yWbx3l7ACNRmu+KZYKUeXQrYzsNMru0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=x0L7KZHk; dkim=pass header.d=linutronix.de header.s=2020e header.b=8746gtP2; spf=pass (imf28.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675889194; a=rsa-sha256; cv=none; b=VfDobfRN/aAo9wSsc3w5dBmKLv58ohr0z+ziErj/IX5vbmjK8VsZnmn4NvgMERkar8ZsfH uGQDFAm5U5IiUMJbGDaobD3PNmj3i+YFE/aZaExiKeGwUM/pCB6GFVYhPEGDv5zBiCrJ+V t5M7aBSyY4ijXT2Xx8qq+zI/HnhP1Gg= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1675889191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=55HBVmJdWZuIgrtPK8UZxNppgqRsonQ+DQObFnSi/4I=; b=x0L7KZHki36WY4RGZv9f5zyyIxc21IkOI3yYRAM8ijjjkfW50Gjn8KNnqK+3zA0CITqybE LM0iOflnlE7xalFEF4frN359DUrSmIw/3Za8jSwdiV/3To5P6QONF9vqpXOwdojIEpQUtR K3z11HS3U2L+zunknnlcaJxJ2ExKo9fWg+/G044Oc62Z281irg1n2Cd/wUoUVJa+9s5KqP Yj0tIL0nJ0vhAIpR7iGthmBehGUJHY3flX/Y9PPCUDYH7ov0aGYZhmlc8zDb0B7+En2p7v zSxhZriUm4bVHcgXQepjGLcP8mutZAtPuoEU8hkREJgqEsRneuP/TpA9H4Cofg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1675889191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=55HBVmJdWZuIgrtPK8UZxNppgqRsonQ+DQObFnSi/4I=; b=8746gtP2K5xw9A9ey3lqEBWNi5JNgEh/GXoXT06u+gHIYiBOr07WBldpSIG0GG2PSlKAW3 NPh6He7fRMP9JtDQ== To: Vlastimil Babka , kernel test robot , Shanker Donthineni Cc: oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Marc Zyngier , Michael Walle , Sebastian Andrzej Siewior , Hans de Goede , Wolfram Sang , linux-mm@kvack.org, "Liam R. Howlett" , Matthew Wilcox , David Rientjes , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Roman Gushchin , Matthew Wilcox Subject: Re: mm, slab/slub: Ensure kmem_cache_alloc_bulk() is available early In-Reply-To: References: <202302011308.f53123d2-oliver.sang@intel.com> <87o7qdzfay.ffs@tglx> <9a682773-df56-f36c-f582-e8eeef55d7f8@suse.cz> <875ycdwyx6.ffs@tglx> <871qn1wofe.ffs@tglx> <6c0b681e-97bc-d975-a8b9-500abdaaf0bc@suse.cz> <8b7762c3-02be-a5c9-1c4d-507cfb51a15c@suse.cz> <87edr1uykw.ffs@tglx> Date: Wed, 08 Feb 2023 21:46:30 +0100 Message-ID: <878rh73mxl.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: x713m6zjpbkd38peeohczjbd54fcchoe X-Rspam-User: X-Rspamd-Queue-Id: B79CFC001A X-Rspamd-Server: rspam06 X-HE-Tag: 1675889193-931111 X-HE-Meta: U2FsdGVkX1/HoQkpd8uN96z01+HdYiTjnyQ8fbzhTNOauHatCvChU0Pg4rkBdFi/tB2ePg5MszGfh/yi38ZgAWnVlrWFUm32k0yICTz4sNTzf8jIFyYyqZYnQgoOyjiSsn1mZ+N/NUwIda2yzJKyx5RdyKoVB0VHkpeBA8+AKfIDhh9nmOOTT9Rj4dNzYiFoVdEOWU0V+8poKj1pdBpxf8cQyph+yU5zz4g83tzvObRVLBvr96ZxrHmmD0EQB9aki96js7w+Y1whZiDIYgmYDKuuDZ8sg2R06zYXZtSBeGjXINYs4RjTqRKKXNPBDpbihmmUOhBnNfMse+uQIkJPIHrXf6jY5iyqMHBHhjAR+IBJQ+CY4TP0OfZ/MUTI96JY0a2+ZrtPeQWbNjd2MwtoNZaDpJ8Ejh3BMzOG5jCMMkTN16wqg2aX2+V0YBa6RNdIX99buldphNhkT/SucKRqwT8FHzvPAMB9llNsL7vVUFKRtQ+jbf/5+7JoBaG6phW6vDwtGHGnKj+7bqVzUc/UHxnbYCwihclZ0t0I89GwcewYdlUpaxhsbdOldlQblbm6D4CTtT6yQYRyORydS6dj2uwhaIgROUWWSBEdpF9Kwh9Oif/ns+UGLyvqhyykKHM2123HramIS+NjsDY+r+7bqjr8mfmp1IT9nZRrei1WoGEUyi5LCslitg+hGTPLvWFotJ97dCk/lR78nKwIhoEJtMhdxfusAl7p4/RdbAjFFXjWrxG01L4jen6uwAIKmawiQQQ9M4Zkhu7lmgXymur0eLFCZluB+gosggORjs8U9SISfDB6FzXwaLsGtTtU2PGUtvTBHbW06bTzl7MnytErJ8ItiA5nnyM/aLB5rnEk9s/ZdT4xq2Eouxx8udUgdVvLj5z0Jd9eQP2AXr5/2ixJ3o0v4qRLhnZRi3OT4kDz/CTcuwX2MicKEuS8lyIFuWXRLN+KQHtXqDgdnU35Xpz m5eIDhcB 4YpX+e9PrKShZkXdmpXxaJGd88JGbo/RwjFSFjk6y5AF4ZmUxuHqrlDTiQ762Bai4w4abhiyeVLsSihSzRn/ZuTnLiflrrGKomyUjHf8Ug4jMcG9MaA24oYM2GONmNPesF75MnSlc6NJh61qzg2UkjAgoBp+U5DducTA5hOuhOxd0UAQyCrVYPbhofU32Q/R2IYcg 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 Wed, Feb 08 2023 at 10:15, Vlastimil Babka wrote: Cc+ Willy > On 2/7/23 19:20, Thomas Gleixner wrote: >> On Tue, Feb 07 2023 at 15:47, Vlastimil Babka wrote: >>> From 340d7c7b99f3e67780f6dec480ed1d27e6f325eb Mon Sep 17 00:00:00 2001 >>> From: Vlastimil Babka >>> Date: Tue, 7 Feb 2023 15:34:53 +0100 >>> Subject: [PATCH] mm, slab/slub: remove notes that bulk alloc/free needs >>> interrupts enabled >>> >>> The slab functions kmem_cache_[alloc|free]_bulk() have been documented >>> as requiring interrupts to be enabled, since their addition in 2015. >>> It's unclear whether that was a fundamental restriction, or an attempt >>> to save some cpu cycles by not having to save and restore the irq >>> flags. >> >> I don't think so. The restriction is rather meant to avoid huge >> allocations in atomic context which causes latencies and also might >> deplete the atomic reserves. > > Fair enough. > >> So I rather avoid that and enforce !ATOMIC mode despite the >> local_irq_save/restore() change which is really only to accomodate with >> early boot. > > We could add some warning then? People might use the bulk alloc unknowingly > again e.g. via maple tree. GFP_KERNEL would warn through the existing > warning, but e.g. GFP_ATOMIC currently not. Correct. > Some maple tree users could use its preallocation instead outside of the > atomic context, when possible. Right. The issue is that there might be maple_tree users which depend on GFP_ATOMIC, but call in from interrupt enabled context, which is legitimate today. Willy might have some insight on that. Thanks, tglx