On Fri, Nov 27, 2009 at 5:08 AM, Balbir Singh <bal...@linux.vnet.ibm.com> wrote: > On Fri, Nov 27, 2009 at 8:15 AM, KAMEZAWA Hiroyuki > <kamezawa.hir...@jp.fujitsu.com> wrote: >> On Fri, 27 Nov 2009 09:20:35 +0900 >> Daisuke Nishimura <nishim...@mxp.nes.nec.co.jp> wrote: >> >>> Hi. >>> > >>> > @@ -73,6 +76,7 @@ void res_counter_uncharge_locked(struct res_counter >>> > *counter, unsigned long val) >>> > val = counter->usage; >>> > >>> > counter->usage -= val; >>> > + res_counter_threshold_notify_locked(counter); >>> > } >>> > >>> hmm.. this adds new checks to hot-path of process life cycle. >>> >>> Do you have any number on performance impact of these patches(w/o setting >>> any threshold)?
No, I don't. I did only functional testing on this stage. >>> IMHO, it might be small enough to be ignored because KAMEZAWA-san's >>> coalesce charge/uncharge >>> patches have decreased charge/uncharge for res_counter itself, but I want >>> to know just to make sure. >>> >> Another concern is to support root cgroup, you need another notifier hook in >> memcg because root cgroup doesn't use res_counter now. >> >> Can't this be implemented in a way like softlimit check ? I'll investigate it. >> Filter by the number of event will be good for notifier behavior, for >> avoiding >> too much wake up, too. Good idea, thanks. > I guess the semantics would vary then, they would become activity > semantics. I think we should avoid threshold notification for root, > since we have no limits in root anymore. Threshold notifications for root cgroup is really needed on embedded systems to avid OOM-killer. > > BTW, Kirill, I've been meaning to write this layer on top of > cgroupstats, is there anything that prevents us from using that today? I'll investigate it. > CC'ing Dan Malek and Vladslav Buzov who worked on similar patches > earlier. > > Balbir Singh. > _______________________________________________ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
