Messages in this thread | | | Date | Tue, 15 Jan 2008 11:16:59 +0100 | From | Nadia Derbey <> | Subject | Re: [RFC PATCH 4/4] [RESEND] Recomputing msgmni on memory add / remove |
| |
Yasunori Goto wrote: >>Yasunori Goto wrote: >> >>>Hello Nadia-san. >>> >>> >>> >>>>@@ -118,6 +122,10 @@ struct ipc_namespace { >>>> size_t shm_ctlall; >>>> int shm_ctlmni; >>>> int shm_tot; >>>>+ >>>>+#ifdef CONFIG_MEMORY_HOTPLUG >>>>+ struct notifier_block ipc_memory_hotplug; >>>>+#endif >>>>}; >>> >>> >>>I'm sorry, but I don't see why each ipc namespace must have each callbacks >>>of memory hotplug. >>>I prefer only one callback for each subsystem, not for each namespace. >>>In addition, the recompute_msgmni() calculation looks very similar for >>>all ipc namespace. >>>Or do you wish each ipc namespace have different callback for the future? >>> >> >>Actually, this is what I wanted to do at the very beginning: have a >>single callback that would recompute the msgmni for each ipc namespace. >>But the issue here is that the namespaces are not linked to each other, >>so I had no simple way to go through all the namespaces. >>I solved the issue by having a callback for any single ipc namespace and >>make it recompute the msgmni value for itslef. > > > The recompute_msg() must be called when new ipc_namespace is created/removed > as you mentioned. I think namespaces should be linked each other for it > in the end....
Not if I do it the same way as for memory hotplug: 1) definee a "namespace event notifier" 2) insert another notifier block into the ipc namespace. 3) The callback routines in the notifier chain would be activated upon namespace creation / removal.
But I'm still thinking about it: Matt Helsley suggested that we might just copy the old namespace's value when creating a new namespace.
There's also the issue of an msgmni that has been changed via procfs: may be we should not unconditionally recompute it upon namespace creation / removal, so unregister the callback for the owning namespace as soon as msgmni has been changed from userspace.
Regards, Nadia
| |