Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp1366829pxb; Fri, 1 Oct 2021 09:09:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyErSdzBY2C3I6drffM9+RWKB19AO8XA88BBi3asGZRk7wh6zrTcYrZwQYnzYt5lh6HPTER X-Received: by 2002:a17:906:3adb:: with SMTP id z27mr7006410ejd.291.1633104567286; Fri, 01 Oct 2021 09:09:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633104567; cv=none; d=google.com; s=arc-20160816; b=uMEv/2LcMO4guyo7P8uyM0YrdJc2C3mhTE4iRHlytmR+xAnJZtE94j1WUYRM7Tzcs3 f7xHdI3QJ1lr8mzCF7UByqwNL4mug1Ha8qkDyU8U5+SdGbE4Ctjfup/WJeeWVPKdZ0VK xS1aXVDC9WNIyUXm5wio8r6ZfF0GhwYOg7e8w+DF9JALLTKyKCZz2z9TAJdQdjznfoBz OwD7qt2L38fMEmfBTgKPR0u0PVNKFLhziWj5iGmH/EfxIU54X4JsokP+HGUEo6aWBsFn NJXs1nVEFg1XrkPurnsZu7c4AZPDM98PfDcgP5R0LhbuyRQgBF3cl2B5Vr8Sfn6l8rkX 57NQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=GNY4mCLAdh6H7+10tLD5snDvXVL71nb/jw0ZWy9yCyw=; b=J7LzZRP+l0qHfzEFtN7dgss3J/IEsB2ZyzelLHuuZhJ4HtQR4vtgsgIfLC7xif2gEC uCr7ULfHKegIbox4WtZNNu+7TV41Stdmgc9dCqQX3fbjK0/Rp6lvOnl52X6i5KKa9hgV BMqsJpfM9MungjWOYJbqJJjknXI/c+xR6ASyxZMXnsGS616Q0YItXYS5JZX2bqQ1Yh8i 1iAaZGSMto7HtChA1gJC0Pr0D2iQusZk4S7UcSuh/tcUShPq/SgNjCAXYynSIb+4SMOu 6oSr0fiMM2/Hk4QD5m7B3msWd87o6zC7NDP0VJ60HAOVjiXbDcFNu4nvbqVYK7tydq/u VmcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lixom-net.20210112.gappssmtp.com header.s=20210112 header.b="bB/8c+kt"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dd16si397601edb.501.2021.10.01.09.09.01; Fri, 01 Oct 2021 09:09:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@lixom-net.20210112.gappssmtp.com header.s=20210112 header.b="bB/8c+kt"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355128AbhJAQBz (ORCPT + 99 others); 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-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