[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <v2lzmdkpdzuwwdnpgncitxenx7aalcjm5zokjgcienshdjfbrr@alnz7zseqxp3>
Date: Wed, 23 Oct 2024 16:08:48 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
cgroups@...r.kernel.org, x86@...nel.org, linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, "Matthew Wilcox (Oracle)" <willy@...radead.org>,
Tejun Heo <tj@...nel.org>, Zefan Li <lizefan.x@...edance.com>,
Johannes Weiner <hannes@...xchg.org>, Michal Koutný <mkoutny@...e.com>,
Jonathan Corbet <corbet@....net>, Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>
Subject: Re: [PATCH v1 08/17] mm/rmap: initial MM owner tracking for large
folios (!hugetlb)
On Thu, Aug 29, 2024 at 06:56:11PM +0200, David Hildenbrand wrote:
> +#ifdef CONFIG_MM_ID
> +/*
> + * For init_mm and friends, we don't allocate an ID and use the dummy value
> + * instead. Limit ourselves to 1M MMs for now: even though we might support
> + * up to 4M PIDs, having more than 1M MM instances is highly unlikely.
> + */
Hm. Should we lower PID_MAX_LIMIT limit then?
Also, do we really need IDA? Can't we derive the ID from mm_struct
address?
> +#define MM_ID_DUMMY 0
> +#define MM_ID_NR_BITS 20
> +#define MM_ID_MIN (MM_ID_DUMMY + 1)
> +#define MM_ID_MAX ((1U << MM_ID_NR_BITS) - 1)
> +#endif /* CONFIG_MM_ID */
> +
> #define MM_MT_FLAGS (MT_FLAGS_ALLOC_RANGE | MT_FLAGS_LOCK_EXTERN | \
> MT_FLAGS_USE_RCU)
> extern struct mm_struct init_mm;
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists