RFC Change default MSGMNI tunable to scale with system memory
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest2 patches 2 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/2 | Scaling msgmni to the system memoryinclude/ ipc/ | +21 | 2 replies | |
| 2/2 | Scaling msgmni to the number of ipc namespacesinclude/ ipc/ ipc/ | +12 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 0/2] Change default MSGMNI tunable to scale with system memory
On large systems we'd like to allow a larger number of message queues. In some cases up to 32K. However simply setting MSGMNI to a larger value may cause problems for smaller systems.
The first patch of this series introduces a default maximum number of message queue ids that scales with the total amount of memory.
Since msgmni is per namespace and there is no amount of memory dedicated to each namespace so far, the second patch of this series scales msgmni to the number of ipc namespaces.
I still have 2 issues that I'll try to solve next:
. use hotplug_memory_notifier() with a callback routine that would recompute
msgmni each time memory is brought offline / online. The issue here is that I couldn't find a simple way to walk through all the nsproxy structures (without walking through the task structures).
. add a new notification mechanism that would recompute all the msg_ctlmni
tunables each time an ipc namespace is created / removed.
These patches should be applied to 2.6.24-rc4, in the following order:
[PATCH 1/2]: ipc_scale_msgmni_with_totalram.patch [PATCH 2/2]: ipc_scale_msgmni_with_namespaces.patch
Note: a big thank to Matt Helsley who gave me a help!
Regards,
Nadia
--