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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BC08C433FE for ; Fri, 1 Oct 2021 16:00:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0302961AD1 for ; Fri, 1 Oct 2021 16:00:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355134AbhJAQBy (ORCPT ); Fri, 1 Oct 2021 12:01:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231434AbhJAQBx (ORCPT ); Fri, 1 Oct 2021 12:01:53 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86738C06177C for ; Fri, 1 Oct 2021 09:00:09 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id r201so3911993pgr.4 for ; Fri, 01 Oct 2021 09:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GNY4mCLAdh6H7+10tLD5snDvXVL71nb/jw0ZWy9yCyw=; b=bB/8c+ktBYRSYiIzc1qYdiubvKawZKgIs8yj4AWJv1gFhGEflb4n8+xq7ndQLzWzsv K2PoREC6WSRvpb/r1htjH2I++9Pd3MKb6hwuYz8yf4RIFihCvaomNe5Wx3EJRw9S5N1x vlaKFUz5kJqPvqnvfliveUpR7z9HK41Xg2uGj0e55vVZuSNT0SF+lkXHftPTsBq2zwN7 R8Dz4h2MllWdZAY5yIvDO9sT/QQFFSPB3d6t+CtS3955sZSk4oMhZ1i+PfTXSjr+4lMF 5dHqYhbtjKCPxPxLaEthOIjBefkcIr+EoEpAyYJ72wR35YGiuIJ/za7Q4La1tnXcJot5 VAjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GNY4mCLAdh6H7+10tLD5snDvXVL71nb/jw0ZWy9yCyw=; b=GI/Y3eviF7hwlIbnlFMl+ivDOk1p9zctcd2D8pzmdXpMNye9T+Tp1VNwx1p92YUPkz 2Wb2NpO3qhlCwrXbLTGN1qH9umFH3+zjRHCbNJqCl4G6LKykORm/LrAhyxAgBIbEYV52 zYNLtDDcRwlX3YXCLSVFrDQNh9CUAgb4eUb/1REkwpaAEXrl/EhVb2dRvoQyhMUCgGKE zg3kxs9XRHgkWcLDObn8Dw3/j0rv9dYgi1VBuSKMCyUGyheyf7P0QA7mciay2ldB0lc4 wLh5/mwhSgSUwxdFXfgQEVlAvru9KOh2WUCnOGPHRftg5UrQvLDY8zbCcTON6EH73gm4 PRrg== X-Gm-Message-State: AOAM532SNycpwSpevskntXiKMWsoTznYvZ4q5z58eLCkOw8asDiDrQvU Y0BWbAhmliwuZtUzz7UQqlntSG2ANWzFGMV7Cjuw8A== X-Google-Smtp-Source: ABdhPJzMhlQ+ie8HM5hyc7yInR7SfxTR/SFzyRo8unfhzRxZHrqwZrqYTWNFAYGA5eeve8rD6AbkmvK5EfkKMBQQF1k= X-Received: by 2002:a05:6a00:16cb:b0:44b:bd38:e068 with SMTP id l11-20020a056a0016cb00b0044bbd38e068mr12092458pfc.34.1633104008868; Fri, 01 Oct 2021 09:00:08 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Olof Johansson Date: Fri, 1 Oct 2021 08:59:57 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Geert Uytterhoeven Cc: Saravana Kannan , Will McVicker , Krzysztof Kozlowski , Russell King , Catalin Marinas , Will Deacon , Michael Turquette , Stephen Boyd , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Linus Walleij , Alessandro Zummo , Alexandre Belloni , John Stultz , Thomas Gleixner , Lee Jones , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , "open list:GPIO SUBSYSTEM" , linux-rtc@vger.kernel.org, Arnd Bergmann Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven wrote: > > Hi Olof, > > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson wrote: > > A much more valuable approach would be to work towards being able to > > free up memory by un-probed drivers at the end of boot. That would > > possibly benefit all platforms on all architectures. > > We used to have such a functionality in arch/ppc (not arch/powerpc!), > where code/data could be tagged __prep, __chrp, or __pmac, to put it > in a special section, and to be freed with initdata when unused. It > was removed in v2.6.15[1], as the savings weren't worth the hassle. > In a more fragmented space like arm the memory lost due to alignment > of the sections would be even more substantial. Yeah, the balance between per-platform code size and overall kernel code size shifted over time to a point where it wasn't as meaningful on ppc. > Another problem is to know when is the end of the boot, especially > with deferred probing. Most of this code either has a module_init() or an initcall that actually registers the drivers and/or probes for the platform and does the work. This means you can have a late equivalent hook/initcall that determines whether this path ended up being probed/used. If it wasn't, you can then unregister and flag the corresponding memory to be freed at the end, and would take out the heuristics and guessing on needing to do it automatically from the code path that's doing said freeing. -Olof 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 484C9C433EF for ; Fri, 1 Oct 2021 16:02:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F0E8F61AE3 for ; Fri, 1 Oct 2021 16:02:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F0E8F61AE3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lixom.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OycX9a8pLnLACB+L5+CQoDvS0JUAgXcXxKpAoYhXMjI=; b=csT6fSfjdHgr9z 13BQK3kleQhUo71RFuR1+zIKZh0hn0+SYYJA+yCnh8/c7qCODGmI3YcNCmRQIoEjMY8MygJ38XRXR CghE20fWtyNpnGBtJSeIVOZi6X04ne2FfukJLNi9EIE4pCcGocZJ6iq+LVi0AY+PPaBv213pk/yJ0 GG5ujvxdRagXtTg6EGlwzNapy9zPodWl/o459yewZeaFRLvuUqCEAUDTfbyLrtTtfbygOuOjb4Gin HgHOPwudlK6FQ9eHCCW/LmByn45pj4KQ6RfFyKC4CefywktfyxsUteUPwuJ2IH4uxZpxyVNFaeJN0 xcV8CJKPo3WFe+FuUzAw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWKxJ-000nJv-KR; Fri, 01 Oct 2021 16:00:13 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWKxG-000nJa-AC for linux-arm-kernel@lists.infradead.org; Fri, 01 Oct 2021 16:00:11 +0000 Received: by mail-pf1-x42a.google.com with SMTP id m26so8346131pff.3 for ; Fri, 01 Oct 2021 09:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lixom-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GNY4mCLAdh6H7+10tLD5snDvXVL71nb/jw0ZWy9yCyw=; b=bB/8c+ktBYRSYiIzc1qYdiubvKawZKgIs8yj4AWJv1gFhGEflb4n8+xq7ndQLzWzsv K2PoREC6WSRvpb/r1htjH2I++9Pd3MKb6hwuYz8yf4RIFihCvaomNe5Wx3EJRw9S5N1x vlaKFUz5kJqPvqnvfliveUpR7z9HK41Xg2uGj0e55vVZuSNT0SF+lkXHftPTsBq2zwN7 R8Dz4h2MllWdZAY5yIvDO9sT/QQFFSPB3d6t+CtS3955sZSk4oMhZ1i+PfTXSjr+4lMF 5dHqYhbtjKCPxPxLaEthOIjBefkcIr+EoEpAyYJ72wR35YGiuIJ/za7Q4La1tnXcJot5 VAjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GNY4mCLAdh6H7+10tLD5snDvXVL71nb/jw0ZWy9yCyw=; b=N4EDWGICvcJB9avnnJ4bpeAheVlzQi+2sSUZ16Ha9X5yDPvsXA06lQzsOB4aXt0Sl4 QbfTCNKXFBkdm10zs0I9jKbpD0ss9XtFVOID7K3Iu7iB5QdcNlJohNYhmh0LmBm4qn25 WlXxxyysE0OQRS6j4tSNL9NawiioHyUG/jsaOuk5KZEsCbVvQW53Qt89tljJNLWn8hGU uNIuCFsHANlAhdUxNGwLk2lOHTliGK1lrVUEhdrJN1h5a9H1jOclyKNwi3UzemVXojaB D5T/vWBqTj7IBZuGz+BxrPP729zd6KsF5wucAwdhUoST/Xk85Hv+mvUvrcK9Rd1kEekx iY1Q== X-Gm-Message-State: AOAM530fTx1rU4MlM9uA1XmevfQwnGF/0D1kVW9m+AH5/3ex/QtNRurn nOm0pFW/DVWc2Z8HEEss+XwSu/iIX9eLtCqC0vgvSw== X-Google-Smtp-Source: ABdhPJzMhlQ+ie8HM5hyc7yInR7SfxTR/SFzyRo8unfhzRxZHrqwZrqYTWNFAYGA5eeve8rD6AbkmvK5EfkKMBQQF1k= X-Received: by 2002:a05:6a00:16cb:b0:44b:bd38:e068 with SMTP id l11-20020a056a0016cb00b0044bbd38e068mr12092458pfc.34.1633104008868; Fri, 01 Oct 2021 09:00:08 -0700 (PDT) MIME-Version: 1.0 References: <20210928235635.1348330-1-willmcvicker@google.com> <7766faf8-2dd1-6525-3b9a-8ba790c29cff@canonical.com> In-Reply-To: From: Olof Johansson Date: Fri, 1 Oct 2021 08:59:57 -0700 Message-ID: Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs To: Geert Uytterhoeven Cc: Saravana Kannan , Will McVicker , Krzysztof Kozlowski , Russell King , Catalin Marinas , Will Deacon , Michael Turquette , Stephen Boyd , Sylwester Nawrocki , Tomasz Figa , Chanwoo Choi , Linus Walleij , Alessandro Zummo , Alexandre Belloni , John Stultz , Thomas Gleixner , Lee Jones , "Cc: Android Kernel" , Linux ARM , Linux Kernel Mailing List , linux-samsung-soc , linux-clk , "open list:GPIO SUBSYSTEM" , linux-rtc@vger.kernel.org, Arnd Bergmann X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211001_090010_401604_7ACE9A35 X-CRM114-Status: GOOD ( 22.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 1, 2021 at 4:59 AM Geert Uytterhoeven wrote: > > Hi Olof, > > On Fri, Oct 1, 2021 at 7:36 AM Olof Johansson wrote: > > A much more valuable approach would be to work towards being able to > > free up memory by un-probed drivers at the end of boot. That would > > possibly benefit all platforms on all architectures. > > We used to have such a functionality in arch/ppc (not arch/powerpc!), > where code/data could be tagged __prep, __chrp, or __pmac, to put it > in a special section, and to be freed with initdata when unused. It > was removed in v2.6.15[1], as the savings weren't worth the hassle. > In a more fragmented space like arm the memory lost due to alignment > of the sections would be even more substantial. Yeah, the balance between per-platform code size and overall kernel code size shifted over time to a point where it wasn't as meaningful on ppc. > Another problem is to know when is the end of the boot, especially > with deferred probing. Most of this code either has a module_init() or an initcall that actually registers the drivers and/or probes for the platform and does the work. This means you can have a late equivalent hook/initcall that determines whether this path ended up being probed/used. If it wasn't, you can then unregister and flag the corresponding memory to be freed at the end, and would take out the heuristics and guessing on needing to do it automatically from the code path that's doing said freeing. -Olof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel