lkml.org 
[lkml]   [2024]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 15/36] lib: introduce support for page allocation tagging
    On Tue, Feb 27, 2024 at 10:30:53AM +0100, Vlastimil Babka wrote:
    >
    >
    > On 2/26/24 18:11, Suren Baghdasaryan wrote:
    > > On Mon, Feb 26, 2024 at 9:07 AM Vlastimil Babka <vbabka@suse.cz> wrote:
    > >>
    > >> On 2/21/24 20:40, Suren Baghdasaryan wrote:
    > >>> Introduce helper functions to easily instrument page allocators by
    > >>> storing a pointer to the allocation tag associated with the code that
    > >>> allocated the page in a page_ext field.
    > >>>
    > >>> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
    > >>> Co-developed-by: Kent Overstreet <kent.overstreet@linux.dev>
    > >>> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    > >>
    > >> The static key usage seems fine now. Even if the page_ext overhead is still
    > >> always paid when compiled in, you mention in the cover letter there's a plan
    > >> for boot-time toggle later, so
    > >
    > > Yes, I already have a simple patch for that to be included in the next
    > > revision: https://github.com/torvalds/linux/commit/7ca367e80232345f471b77b3ea71cf82faf50954
    >
    > This opt-out logic would require a distro kernel with allocation
    > profiling compiled-in to ship together with something that modifies
    > kernel command line to disable it by default, so it's not very
    > practical. Could the CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT be
    > turned into having 3 possible choices, where one of them would
    > initialize mem_profiling_enabled to false?
    >
    > Or, taking a step back, is it going to be a common usecase to pay the
    > memory overhead unconditionally, but only enable the profiling later
    > during runtime? Also what happens if someone would enable and disable it
    > multiple times during one boot? Would the statistics get all skewed
    > because some frees would be not accounted while it's disabled?

    I already wrote the code for fast lookup from codetag index -> codetag -
    i.e. pointer compression - so this is all going away shortly.

    It just won't be in the initial pull request because of other
    dependencies (it requires my eytzinger code, which I was already lifting
    from fs/bcachefs/ for 6.9), but it can still probably make 6.9 in a
    second smaller pull.

    \
     
     \ /
      Last update: 2024-05-27 15:24    [W:4.149 / U:1.764 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site