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 A8E14C43217 for ; Fri, 1 Oct 2021 16:00:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 89AE961ACF for ; Fri, 1 Oct 2021 16:00:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355138AbhJAQBz (ORCPT ); Fri, 1 Oct 2021 12:01:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355130AbhJAQBy (ORCPT ); Fri, 1 Oct 2021 12:01:54 -0400 Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A1D58C06177F for ; Fri, 1 Oct 2021 09:00:09 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id e7so9845456pgk.2 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=H3pUfyUGbjK+ENG4GpQ9nTphJP9sbuhzHrrDonb0yC3ijqG7Ld0V8gWf9JogCQkLxY v1OZFCIo1CuyQw6u1Jphew8pMqOL2goQwv56gfsuw3sf2mWJxfCTHQReqba4BQQ6M0jm 0vzztwutyyzpMj0O7eJOpA+CTZchQfEJnwAybfghZBfIfrOiq2s5LtVZlBZLy8Z0D+2v 7Wzzzd8dXpVSKbJ7Al4HhntXYcdMeIVq6AhoD6VCb0jGB91mo33fNiI1Hcd9Jwg/e68X DDu5yOwlvCXODT8iZfVjQ8xZpQW9XSROjwlQvXvesq9FC33WzuLvU7pXJxIEw1r9HVTk lC2g== X-Gm-Message-State: AOAM533vwULP3FRvKaZmgZzoxMyXyaOk1YcaONgio0GhffF4W36GLXyD n6BBpKoi3wBH/sxKfeWgkbNtiT/g77YrlzTpmEkDwQ== 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-kernel@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