Message-ID: <62a7eb3f-fb27-43f4-8365-0fa0456c2f01@redhat.com>
Date: Mon, 21 Oct 2024 11:13:48 +0200
From: David Hildenbrand <david@...hat.com>
To: Michal Hocko <mhocko@...e.com>, Suren Baghdasaryan <surenb@...gle.com>
Cc: John Hubbard <jhubbard@...dia.com>, Yosry Ahmed <yosryahmed@...gle.com>,
 akpm@...ux-foundation.org, kent.overstreet@...ux.dev, corbet@....net,
 arnd@...db.de, mcgrof@...nel.org, rppt@...nel.org, paulmck@...nel.org,
 thuth@...hat.com, tglx@...utronix.de, bp@...en8.de,
 xiongwei.song@...driver.com, ardb@...nel.org, vbabka@...e.cz,
 hannes@...xchg.org, roman.gushchin@...ux.dev, dave@...olabs.net,
 willy@...radead.org, liam.howlett@...cle.com, pasha.tatashin@...een.com,
 souravpanda@...gle.com, keescook@...omium.org, dennis@...nel.org,
 yuzhao@...gle.com, vvvvvv@...gle.com, rostedt@...dmis.org,
 iamjoonsoo.kim@....com, rientjes@...gle.com, minchan@...gle.com,
 kaleshsingh@...gle.com, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
 linux-mm@...ck.org, linux-modules@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v3 5/5] alloc_tag: config to store page allocation tag
 refs in page flags



Am 21.10.24 um 09:26 schrieb Michal Hocko:
> On Fri 18-10-24 14:57:26, Suren Baghdasaryan wrote:
>> On Fri, Oct 18, 2024 at 10:45 AM Suren Baghdasaryan <surenb@...gle.com> wrote:
>>>
>>> On Fri, Oct 18, 2024 at 10:08 AM Michal Hocko <mhocko@...e.com> wrote:
>>>
>>> Automatic fallback is possible during boot, when we decide whether to
>>> enable page extensions or not. So, if during boot we decide to disable
>>> page extensions and use page flags, we can't go back and re-enable
>>> page extensions after boot is complete. Since there is a possibility
>>> that we run out of page flags at runtime when we load a new module,
>>> this leaves this case when we can't reference the module tags and we
>>> can't fall back to page extensions, so we have to disable memory
>>> profiling.
>>> I could keep page extensions always on just in case this happens but
>>> that's a lot of memory waste to handle a rare case...
>>
>> After thinking more about this, I suggest a couple of changes that
>> IMHO would make configuration simpler:
>> 1. Change the CONFIG_PGALLOC_TAG_USE_PAGEFLAGS to an early boot
>> parameter.
> 
> This makes much more sense!
> 
>> Today we have a "mem_profiling" parameter to enable/disable
>> memory profiling. I suggest adding "mem_profiling_use_pgflags" to
>> switch the current behavior of using page extensions to use page
>> flags.
> 
> I do not want to bikeshed about this but to me it would make more sense
> to have an extension paramater to mem_profiling and call it something
> like compress or similar so that page flags are not really carved into
> naming. The docuemntation then can explain that the copression cannot be
> always guaranteed and it might fail so this is more of a optimistic and
> potentially failing optimization that might need to be dropped in some
> usege scenarios.

Maybe we can reuse the existing parameter (e.g., tristate). Only makes sense if 
we don't expect too many other modes though :)

> 
>> We keep the current behavior of using page extensions as
>> default (mem_profiling_use_pgflags=0) because it always works even
>> though it has higher overhead.
> 
> Yes this seems to be a safe default.

Agreed.

> 
>> 2. No auto-fallback. If mem_profiling_use_pgflags=1 and we don't have
>> enough page flags (at boot time or later when we load a module), we
>> simply disable memory profiling with a warning.

Sounds reasonable to me.

-- 
Cheers,

David / dhildenb

Powered by blists - more mailing lists