On Mon, Oct 21, 2024 at 2:13 AM David Hildenbrand <david@xxxxxxxxxx> wrote: > > > > 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@xxxxxxxxxx> wrote: > >>> > >>> On Fri, Oct 18, 2024 at 10:08 AM Michal Hocko <mhocko@xxxxxxxx> 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 :) Yeah, I thought about adding new values to "mem_profiling" but it's a bit complicated. Today it's a tristate: mem_profiling=0|1|never 0/1 means we disable/enable memory profiling by default but the user can enable it at runtime using a sysctl. This means that we enable page_ext at boot even when it's set to 0. "never" means we do not enable page_ext, memory profiling is disabled and sysctl to enable it will not be exposed. Used when a distribution has CONFIG_MEM_ALLOC_PROFILING=y but the user does not use it and does not want to waste memory on enabling page_ext. I can add another option like "pgflags" but then it also needs to specify whether we should enable or disable profiling by default (similar to 0|1 for page_ext mode). IOW we will need to encode also the default state we want. Something like this: mem_profiling=0|1|never|pgflags_on|pgflags_off Would this be acceptable? > > > > >> 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 >
