On Thursday 25 October 2012 18:37:25 Dhaval Giani wrote: > On Thu, Oct 25, 2012 at 2:32 PM, jbd <j...@jbdenis.net> wrote: > >>.. I need to defined a different hierarchy for > >> each process to apply the memory limit the way I want it's the same for me ;)
> ...I don't think it > should be too complicated to create cgroups with cgrules dynamically. If the task is created in the default cgroup, it could exceed its quota before being migrated to the given cgroup. > The hard questions are policy related. Let's take just the memory > subsystem for example, > 1. When do you know the memory limit? Usually the memory limit is known before starting the process, so it could be a candidate for cgrules. > I don't think either of the methods are harder than the > other, but it really is a question of knowing what interface to > provide. > 2. What if memory is co-mounted with (say) cpusets? cpusets bring > about interesting complications, since you cannot move a process into > them till the cpus and memory is set. How do you figure out what to do > for cpuset when all your program cares about is memory? Can you please provide a simple use-case that would be broken while setting a per-process memory limit? > I think that Roberto Polli (see the thread "[patching...] trying to add > per-process limits on memory subsystem." from yesterday) is already > working in the right direction (from my user point of view of course). Looking at the sources it seems that switching from a group-based accounting to a per-process accounting is not straightforward: it really requires creating a new cgroup for every process... Probably the RSS limit should be re-implemented at the core kernel level (iirc 2.4.29 supported it) but i still didn't find the reason of its removal... > Now, I am sure > we can have a solution for you, but I am also sure that I will find at > least 10 persons coming and telling me that that policy is broken ;-). no pain no gain ;) > So, I am very happy to accept patches (at least to create cgroups > dynamically), however I would like some sane policy mechanism, and if > you figure it out, you are my hero :D. Dynamic cgroup creation requires some sort of templating. > > Thanks! > Dhaval > > ---------------------------------------------------------------------------- > -- Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Libcg-devel mailing list > Libcg-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libcg-devel -- Roberto Polli Community Manager Babel S.r.l. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere confidenziale per i destinatari in indirizzo. E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati nel messaggio originale. Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di comunicarlo al mittente e cancellarlo immediatamente. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
