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 BAE96C433FE for ; Mon, 3 Oct 2022 08:18:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 23F598E0001; Mon, 3 Oct 2022 04:18:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1EFBE6B0073; Mon, 3 Oct 2022 04:18:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B88E8E0001; Mon, 3 Oct 2022 04:18:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EAF0D6B0072 for ; Mon, 3 Oct 2022 04:18:00 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B8BD71409EB for ; Mon, 3 Oct 2022 08:18:00 +0000 (UTC) X-FDA: 79978935120.12.CB695B4 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) by imf20.hostedemail.com (Postfix) with ESMTP id 5A28D1C0023 for ; Mon, 3 Oct 2022 08:17:59 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id v1so9036659plo.9 for ; Mon, 03 Oct 2022 01:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=8j6ZKu0VKQ7UFJHYONa1qnlLnHrkBbn87LJDOHuo5pQ=; b=gbBjONrirBqX/bI3ZAv2UuJ7gVnMy8FTTYPnc879Vb9MF47QxSX3gUYMSth08JQAw2 mkCwuMehND9/qeXTnM42n4MXglWyoW5TK7wnLDN55DiMKRDjSnlIx2tVtD2ihWY6cLaY TZOr11+sg0vEz32n9aT6u42SIB4b2YPjp5lqZSIQnV8hP1K6rz9fXAgQ9A6YqrtwDwe6 odrzKDr4OuKH4Q9Q5PiU3GOtrC8AtzdaEMNjKJUHBmgkFa+m5ndIQ9rcgs//OGZd4GHG Rl2lwiQojp+8lGexyJDhSOoqOpALeDtHPmcSCRerLZICpyEdlu/3Oo3z3tsHDyw8+0+s t6HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=8j6ZKu0VKQ7UFJHYONa1qnlLnHrkBbn87LJDOHuo5pQ=; b=oaLX+ZYOM86mtMkpMzgBmz0xkuX7T8whApDmkBESvAvhbHq8ZJuYiZeAyZk0z9siDQ J8l6Vtdyq/WjHWGsMZZQM6cSStS9RBleykFOoWFFwiA+MTFMteUXMOSr+zY1DGE7SwKD wyI091+8hoMgadXQs/khYLwHp2llmOgVnnpw1XybXHaP/AUzXG3dkLQjd52QVSG69KOM 15dR+CI5jPTUb29PtNPn5B49O2Q31Ac9lVHukSe04QU3j3Mjbn41INRiEsWDzC5JzF2Z GRzDhncdR8EWizb24WpWPvG3x19X0w1YI+Ry87OyGyUUssNJdK5NO4sqGSuTddzXZoEq J1BA== X-Gm-Message-State: ACrzQf1dm5vMbs1d/9P657/uaPAnT/ewN+OQ4Y8g9S/oYyT4QirNJPR6 eT7hpvHJP7eN7Y3lrN1sk6w= X-Google-Smtp-Source: AMsMyM55PTHgWjtRPxqW1UZf2+dEwuUCiTSZcSixQtt+bFmZS43MzpXtzrwQsB8UqvEzsk03XieqRA== X-Received: by 2002:a17:90a:fe13:b0:20a:8fc8:60ec with SMTP id ck19-20020a17090afe1300b0020a8fc860ecmr6081911pjb.69.1664785078153; Mon, 03 Oct 2022 01:17:58 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id s17-20020a170903215100b00173411a4385sm6594953ple.43.2022.10.03.01.17.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Oct 2022 01:17:57 -0700 (PDT) Date: Mon, 3 Oct 2022 17:17:51 +0900 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Rasmus Villemoes Cc: Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: slub: make slab_sysfs_init() a late_initcall Message-ID: References: <20220930102712.789755-1-linux@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220930102712.789755-1-linux@rasmusvillemoes.dk> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664785079; 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=8j6ZKu0VKQ7UFJHYONa1qnlLnHrkBbn87LJDOHuo5pQ=; b=AFCwRcARmRqlBInrKgkw38p5Cj/esgwNE1/2QA+dG5vXsWg6KK69IUHTC6SwxFBXKjAJuA H1QLvFRqVpf56PZadrsU+i2s5MJHf7BhraBizTfVc8uO+GF8ExNqRSBYBUr4nBYtCXLVzK Ojh6L9GrP2C6UfOM2utC7ARANOTHZlQ= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gbBjONri; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664785079; a=rsa-sha256; cv=none; b=FWjqgrgGJalTokHeYOrikI0zaKR2efyjy/DDNw/uQWND0jxfyEhfaM6tTlVucXrsWBQLaQ GEo5Z4TFQjDYDWhYgTTGEgP/pU+Oo1ZeSrXE35cdIXRpVhqas93tfeW9oLfDH4KLr3517p UwrXHOb751wjnJ3aMuLSCh3g0bZTEAc= X-Stat-Signature: xjmomes49wba45izw5zb5aubsubpgjye X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 5A28D1C0023 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=gbBjONri; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.214.178 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com X-HE-Tag: 1664785079-294716 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 Fri, Sep 30, 2022 at 12:27:12PM +0200, Rasmus Villemoes wrote: > Currently, slab_sysfs_init() is an __initcall aka device_initcall. It > is rather time-consuming; on my board it takes around 11ms. That's > about 1% of the time budget I have from U-Boot letting go and until > linux must assume responsibility of keeping the external watchdog > happy. > > There's no particular reason this would need to run at device_initcall > time, so instead make it a late_initcall to allow vital functionality > to get started a bit sooner. > > This actually ends up winning more than just those 11ms, because the > slab caches that get created during other device_initcalls (and before > my watchdog device gets probed) now don't end up doing the somewhat > expensive sysfs_slab_add() themselves. Some example lines (with > initcall_debug set) before/after: > > initcall ext4_init_fs+0x0/0x1ac returned 0 after 1386 usecs > initcall journal_init+0x0/0x138 returned 0 after 517 usecs > initcall init_fat_fs+0x0/0x68 returned 0 after 294 usecs > > initcall ext4_init_fs+0x0/0x1ac returned 0 after 240 usecs > initcall journal_init+0x0/0x138 returned 0 after 32 usecs > initcall init_fat_fs+0x0/0x68 returned 0 after 18 usecs > > Altogether, this means I now get to petting the watchdog around 17ms > sooner. [Of course, the time the other initcalls save is instead spent > in slab_sysfs_init(), which goes from 11ms to 16ms, so there's no > overall change in boot time.] This looks okay and just curious, can you explain what kind of benefit does enabling watchdog early provides? > Signed-off-by: Rasmus Villemoes > --- > > The numbers certainly suggest that someone might want to look into > making sysfs/kobject/kset perform better. But that would be way more > complicated than this patch, and could not possibly achieve the same > win as getting the sysfs_slab_add() overhead completely out of the > way. > > > mm/slub.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index 4b98dff9be8e..dade5c84a7bb 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -6070,8 +6070,7 @@ static int __init slab_sysfs_init(void) > mutex_unlock(&slab_mutex); > return 0; > } > - > -__initcall(slab_sysfs_init); > +late_initcall(slab_sysfs_init); > #endif /* CONFIG_SYSFS */ > > #if defined(CONFIG_SLUB_DEBUG) && defined(CONFIG_DEBUG_FS) > -- > 2.37.2 This is only deferring slub's sysfs initialization step (still before init process) So IIUC it shouldn't be serious. -- Thanks, Hyeonggon