Messages in this thread | | | Date | Tue, 15 Dec 2009 17:07:05 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [PATCH RFC v2 3/4] memcg: rework usage of stats by soft limit |
| |
On Tue, 15 Dec 2009 09:48:09 +0200 "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
> On Tue, Dec 15, 2009 at 3:35 AM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > On Sat, 12 Dec 2009 21:46:08 +0200 > > "Kirill A. Shutemov" <kirill@shutemov.name> wrote: > > > >> On Sat, Dec 12, 2009 at 4:34 PM, Daisuke Nishimura > >> <d-nishimura@mtf.biglobe.ne.jp> wrote: > >> > On Sat, 12 Dec 2009 15:06:52 +0200 > >> > "Kirill A. Shutemov" <kirill@shutemov.name> wrote: > >> > > >> >> On Sat, Dec 12, 2009 at 5:50 AM, Daisuke Nishimura > >> >> <d-nishimura@mtf.biglobe.ne.jp> wrote: > >> >> > And IIUC, it's the same for your threshold feature, right ? > >> >> > I think it would be better: > >> >> > > >> >> > - discard this change. > >> >> > - in 4/4, rename mem_cgroup_soft_limit_check to mem_cgroup_event_check, > >> >> > and instead of adding a new STAT counter, do like: > >> >> > > >> >> > if (mem_cgroup_event_check(mem)) { > >> >> > mem_cgroup_update_tree(mem, page); > >> >> > mem_cgroup_threshold(mem); > >> >> > } > >> >> > >> >> I think that mem_cgroup_update_tree() and mem_cgroup_threshold() should be > >> >> run with different frequency. How to share MEM_CGROUP_STAT_EVENTS > >> >> between soft limits and thresholds in this case? > >> >> > >> > hmm, both softlimit and your threshold count events at the same place(charge and uncharge). > >> > So, I think those events can be shared. > >> > Is there any reason they should run in different frequency ? > >> > >> SOFTLIMIT_EVENTS_THRESH is 1000. If use the same value for thresholds, > >> a threshold can > >> be exceed on 1000*nr_cpu_id pages. It's too many. I think, that 100 is > >> a reasonable value. > >> > > > > Hmm, then what amount of costs does this code add ? > > > > Do you have benchmark result ? > > I've post some numbers how the patchset affects performance: > http://article.gmane.org/gmane.linux.kernel.mm/41880 > > Do you need any other results? > Ah, sorry. I missed that. The numbers seems good.
(off topic) multi-fault is too special, It's just a my toy ;)
The test I recommend you is kernel-make on tmpfs. This is my setup script. == #!/bin/sh
mount -t tmpfs none /home/kamezawa/tmpfs cp /home/kamezawa/linux-2.6.30.tar.bz2 /home/kamezawa/tmpfs cd /home/kamezawa/tmpfs mkdir /home/kamezawa/tmpfs/tmp tar xvpjf linux-2.6.30.tar.bz2 cd linux-2.6.30 make defconfig
and making gcc's tmporarly strage(TMPDIR) on tmpfs.
#make clean; make -j 8 or some.
and check "stime"
But I don't ask you to do this, now. The whole patch seems attractive to me. Please fix something pointed out.
I stop my patches for memcg's percpu counter rewriting until yours and Nishimura's patch goes. You can leave your threshold-event-counter as it is. I'll think of I can do total-rewrite of that counter or not.
Thanks, -Kame
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |