On 23.10.24 15:08, Kirill A. Shutemov wrote:
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?
Note that each thread gets a PID, but all threads share a MM struct.
Also we are concerned about PID reuse, but not for MM IDs.
So I don't think we should be touching PID_MAX_LIMIT.
Also, do we really need IDA? Can't we derive the ID from mm_struct
address?
Yes, that's the whole purpose of it. We need something < 30bit to save
space in struct page.
The description touches on that:
"As we have to squeeze this information into the "struct folio" of even
folios of order-1 (2 pages), and we generally want to reduce the
required metadata, we'll assign each MM a unique ID that consumes less
than 32 bit. We'll limit the IDs to 20bit / 1M for now: we could allow
for up to 30bit, but getting even 1M IDs is unlikely in practice. If
required, we could raise the limit later, and the 1M limit might come in
handy in the future with other tracking approaches."
--
Cheers,
David / dhildenb
