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 27163C433FE for ; Thu, 6 Oct 2022 06:06:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D3116B0071; Thu, 6 Oct 2022 02:06:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 081F16B0073; Thu, 6 Oct 2022 02:06:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E64736B0074; Thu, 6 Oct 2022 02:06:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D1A786B0071 for ; Thu, 6 Oct 2022 02:06:38 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A4A9AA01B0 for ; Thu, 6 Oct 2022 06:06:38 +0000 (UTC) X-FDA: 79989490476.10.C9A4E8C Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf05.hostedemail.com (Postfix) with ESMTP id 34F4D10001B for ; Thu, 6 Oct 2022 06:06:37 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id e129so968174pgc.9 for ; Wed, 05 Oct 2022 23:06:37 -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=xCHI/r7UbHwyMZPNpnw09K/IltGzRjSwUGHvdJZJsaQ=; b=QkivrckY6BxtU90PHTS9urU/QFYuYV6A8No2pgvWCYaKaWnfwnXwXn9n9Hlu7rc9Gz PF8J38OvUjMTABPhNOzmwZgWrUsnHspOTYs8eCei5wKHxQqNFti1+zpKRMZ0xOnZ/jXn fYjN0fJmgkdlnGmDGws/L2QHaFAKvLplJIK50d4H2ahNtOCfFi7PlwQLTxuMdFWdoA7R eCPSAqvjtcvDcMzrUmpGdCR909NGPds6ePz7Me9zVz5d+nwjCEWE3doHTZyp2kzuqDVg BgvKey+ESWYQ0c78/6tDcnVY/ZhAygnzc8QpbZIeCSCrhvw0UWQ9xXJ2MP1WPNBamrF8 R+lA== 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=xCHI/r7UbHwyMZPNpnw09K/IltGzRjSwUGHvdJZJsaQ=; b=0lsLuKwu/dnaOuMI94sr7dhYLDMqB5ySjtiZvtHkIT0vZQm6ySNnuPCOqjAYYn53KV Q0RjdeFNqwiA0xBWwtT4V1aTXuAs9NCbDdqCWJwYXFMeAQK2Bvvsq3rzww/3IcePs0LZ rC3ik59iepNniJZ6hl7kDfbRwEFkoxZg2CaDEXeR3fLj5zgkaNVMimwFcnei3M/rOxyM uyhDk9aDppJFhDWCFV/f/yy3jLRbtYN51VC+wOZxIggW/jLZ83UF3Irs4VnHS4AlH3+B aP+61qvWWF63bEq+Rxx1bxcR9b2MEhE/NgTj7cwWY++5fzwoMWETvO9f54mXoQcWEIIe wXMw== X-Gm-Message-State: ACrzQf06dTxdy17mfztfvK0+OpZ0FDb9sg6tdkRN6wuUzAhlnoJtBN7+ 2Kpq90iizUZSy7peQVTix3E= X-Google-Smtp-Source: AMsMyM5agK3pdJJ+CB5+aM16SGzZhNY7z2jpRBmI86Eu3yEmvdH1YWJ1IZj/IB7pOOcFUn0QFo4Crw== X-Received: by 2002:a05:6a00:1304:b0:555:6d3f:1223 with SMTP id j4-20020a056a00130400b005556d3f1223mr3507945pfu.60.1665036397054; Wed, 05 Oct 2022 23:06:37 -0700 (PDT) Received: from hyeyoo ([114.29.91.56]) by smtp.gmail.com with ESMTPSA id s10-20020a170902ea0a00b00172fad607b3sm11589190plg.207.2022.10.05.23.06.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Oct 2022 23:06:35 -0700 (PDT) Date: Thu, 6 Oct 2022 15:06:30 +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: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665036398; 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=xCHI/r7UbHwyMZPNpnw09K/IltGzRjSwUGHvdJZJsaQ=; b=nDoAzIDzoqc0WwpJa0Hzp5FCePDtlA2qPZHu3mOiJFRl/UI6QFekAwtXwlunZSKWsHvIpg PuKAiSFi5kACr9q7h2+/tgBzpTrvbbKUFIlY1Eeq1sNp5FQOeeSKxY4+1LumDMGR6kuB08 V4QcIA0oxU9sNoE0I6mJAi7KtY4R620= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QkivrckY; spf=pass (imf05.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665036398; a=rsa-sha256; cv=none; b=dyB6OGBTuz21jyUvJBOBJBZWgsQPluT8CrjDc/yMH0yQR2D8l6/Fzq2+6Deau8pc+89pva ANJGz4l7o6H/8vFNevUjFa5yEdvLYF1mYEcTxLkXx0qJH5oSbL0C2R3FDuoqIDPPdevo4i kEQKa9LG7qW1h2IHvcZeHJJ/F8t883A= X-Rspamd-Queue-Id: 34F4D10001B Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QkivrckY; spf=pass (imf05.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.172 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam06 X-Rspam-User: X-Stat-Signature: 5bcjogcrc48wpx8odptkzatpnczusnt5 X-HE-Tag: 1665036397-852693 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 Mon, Oct 03, 2022 at 12:25:26PM +0200, Rasmus Villemoes wrote: > On 03/10/2022 10.17, Hyeonggon Yoo wrote: > > 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? > > The watchdog is _always_ enabled, from power-on onwards. There's nothing > one can do to disable it (short of using a soldering iron to modify the > board...), and usually nothing one can do to program its timeout [if it > is at all configurable, it's done during board design using appropriate > resistor/capacitor values]. > > All the custom boards I've met, across the very different industries > I've worked with, have always had such an external watchdog. Their > timing requirements may vary; currently I'm working on a board which has > a 1s margin, but I've also encountered something as low as (IIRC) 400ms. > > While 10-20ms may not sound impressive, this is not the first nor the > last patch I'm trying to get upstream (see e7cb072eb988 for another > example, done in connection with another project) to gain as much margin > as possible - we want to be able to continue to upgrade our kernels for > the next 5, 10, 20 years, and undoubtedly the mainline kernel will grow > features and overhead in that timespan which won't be offset by better > compilers. > > Rasmus Thank you for such a detailed explanation. Now I get your motivation for this. To best of my knowledge 1) it is not increasing boot time significantly as it is just postponing slab_sysfs_init(), and 2) it is still before init process so some systemd scripts interacting with SLUB sysfs interface ran just after boot won't be broken (and at least on my machine it didn't). Thus.. Acked-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Thanks! -- Thanks, Hyeonggon