OpenVZ Forum - RDF feed
type: channel
items: [RFC] [PATCH] memory controller background reclamation
items: Re: [RFC] [PATCH] memory controller background reclamation
items: Re: Re: [RFC] [PATCH] memory controller background reclamation

[RFC] [PATCH] memory controller background reclamation
type: item
description: hi, i implemented background reclamation for your memory controller and did a few benchmarks with and without it. any comments? YAMAMOTO Takashi ----- "time make -j4 bzImage" in a cgroup with 64MB limit: without patch: real 22m22.389s user 13m35.163s sys 6m12.283s memory.failcnt after a run: 106647 with patch: real 19m25.860s user 14m10.549s sys 6m13.831s memory.failcnt after a run: 35366 "for x in 1 2 3;do time dd if=/dev/zero bs=1M count=300|tail;done" in a cgroup with 16MB limit: without patch: 300+0 records in 300+0 records out 314572800 bytes (315 MB) copied, 19.0058 seconds, 16.6 MB/s u 0.00s s 0.67s e 19.01s maj 90 min 2021 in 0 out 0 u 0.48s s 7.22s e 93.13s maj 20475 min 210903 in 0 out 0 300+0 records in 300+0 records out 314572800 bytes (315 MB) copied, 14.8394 seconds, 21.2 MB/s u 0.00s s 0.63s e 14.84s maj 53 min 1392 in 0 out 0 u 0.48s s 7.00s e 94.39s maj 20125 min 211145 in 0 out 0 300+0 records in 300+0 records out 314572800 bytes (315 MB) copied, 14.0635 seconds, 22.4 MB/s u 0.01s s 0.59s e 14.07s maj 50 min 1385 in 0 out 0 u 0.57s s 6.93s e 91.54s maj 20359 min 210911 in 0 out 0 memory.failcnt after a run: 8804 with patch: 300+0 records in 300+0 records out 314572800 bytes (315 MB) copied, 5.94875 seconds, 52.9 MB/s u 0.00s s 0.67s e 5.95s maj 206 min 5393 in 0 out 0 u 0.45s s 6.63s e 46.07s maj 21350 min 210252 in 0 out 0 300+0 records in 300+0 records out 314572800 bytes (315 MB) copied, 8.16441 seconds, 38.5 MB/s u 0.00s s 0.60s e 8.17s maj 240 min 4614 in 0 out 0 u 0.45s s 6.56s e 54.56s maj 22298 min 209255 in 0 out 0 300+0 records in 300+0 records out 314572800 bytes (315 MB) copied, 4.60967 seconds, 68.2 MB/s u 0.00s s 0.60s e 4.64s maj 196 min 4733 in 0 out 0 u 0.46s s 6.53s e 49.28s maj 22223 min 209384 in 0 out 0 memory.failcnt after a run: 1589 ----- --- linux-2.6.23-rc8-mm2-cgkswapd/mm/memcontrol.c.BACKUP 2007-10-01 17:19:57.000000000 +0900 +++ linux-2.6.23-rc8-mm2-cgkswapd/mm/memcontrol.c 2007-10-22 13:46:01.000000000 +0900 @@ -27,6 +…
creator: yamamoto
date: 2007-10-22T09:43:49-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: YAMAMOTO Takashi wrote: > hi, > > i implemented background reclamation for your memory controller and > did a few benchmarks with and without it. any comments? > > YAMAMOTO Takashi > > > ----- > "time make -j4 bzImage" in a cgroup with 64MB limit: > > without patch: > real 22m22.389s > user 13m35.163s > sys 6m12.283s > > memory.failcnt after a run: 106647 > > with patch: > real 19m25.860s > user 14m10.549s > sys 6m13.831s > > memory.failcnt after a run: 35366 > > "for x in 1 2 3;do time dd if=/dev/zero bs=1M count=300|tail;done" > in a cgroup with 16MB limit: > > without patch: > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 19.0058 seconds, 16.6 MB/s > u 0.00s s 0.67s e 19.01s maj 90 min 2021 in 0 out 0 > u 0.48s s 7.22s e 93.13s maj 20475 min 210903 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 14.8394 seconds, 21.2 MB/s > u 0.00s s 0.63s e 14.84s maj 53 min 1392 in 0 out 0 > u 0.48s s 7.00s e 94.39s maj 20125 min 211145 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 14.0635 seconds, 22.4 MB/s > u 0.01s s 0.59s e 14.07s maj 50 min 1385 in 0 out 0 > u 0.57s s 6.93s e 91.54s maj 20359 min 210911 in 0 out 0 > > memory.failcnt after a run: 8804 > > with patch: > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 5.94875 seconds, 52.9 MB/s > u 0.00s s 0.67s e 5.95s maj 206 min 5393 in 0 out 0 > u 0.45s s 6.63s e 46.07s maj 21350 min 210252 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 8.16441 seconds, 38.5 MB/s > u 0.00s s 0.60s e 8.17s maj 240 min 4614 in 0 out 0 > u 0.45s s 6.56s e 54.56s maj 22298 min 209255 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 4.60967 seconds, 68.2 MB/s > u 0.00s s 0.60s e 4.64s maj 196 min 4733 in 0 out 0 > u 0.46s s 6.53s e 49.28s maj 22223 min 209384 in 0 out 0 > > memory.failcnt after a run: 1589 Looks quite nice! > ----- > > > --- linux…
creator: Balbir Singh
date: 2007-10-22T16:10:45-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: YAMAMOTO Takashi wrote: > hi, > > i implemented background reclamation for your memory controller and > did a few benchmarks with and without it. any comments? > > YAMAMOTO Takashi > > > ----- > "time make -j4 bzImage" in a cgroup with 64MB limit: > > without patch: > real 22m22.389s > user 13m35.163s > sys 6m12.283s > > memory.failcnt after a run: 106647 > > with patch: > real 19m25.860s > user 14m10.549s > sys 6m13.831s > > memory.failcnt after a run: 35366 > > "for x in 1 2 3;do time dd if=/dev/zero bs=1M count=300|tail;done" > in a cgroup with 16MB limit: > > without patch: > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 19.0058 seconds, 16.6 MB/s > u 0.00s s 0.67s e 19.01s maj 90 min 2021 in 0 out 0 > u 0.48s s 7.22s e 93.13s maj 20475 min 210903 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 14.8394 seconds, 21.2 MB/s > u 0.00s s 0.63s e 14.84s maj 53 min 1392 in 0 out 0 > u 0.48s s 7.00s e 94.39s maj 20125 min 211145 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 14.0635 seconds, 22.4 MB/s > u 0.01s s 0.59s e 14.07s maj 50 min 1385 in 0 out 0 > u 0.57s s 6.93s e 91.54s maj 20359 min 210911 in 0 out 0 > > memory.failcnt after a run: 8804 > > with patch: > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 5.94875 seconds, 52.9 MB/s > u 0.00s s 0.67s e 5.95s maj 206 min 5393 in 0 out 0 > u 0.45s s 6.63s e 46.07s maj 21350 min 210252 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 8.16441 seconds, 38.5 MB/s > u 0.00s s 0.60s e 8.17s maj 240 min 4614 in 0 out 0 > u 0.45s s 6.56s e 54.56s maj 22298 min 209255 in 0 out 0 > 300+0 records in > 300+0 records out > 314572800 bytes (315 MB) copied, 4.60967 seconds, 68.2 MB/s > u 0.00s s 0.60s e 4.64s maj 196 min 4733 in 0 out 0 > u 0.46s s 6.53s e 49.28s maj 22223 min 209384 in 0 out 0 > > memory.failcnt after a run: 1589 > ----- Results looks good. Background re…
creator: Vaidyanathan Srinivas
date: 2007-10-22T17:06:40-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: hi, > > @@ -250,6 +256,69 @@ unsigned long mem_cgroup_isolate_pages(u > > return nr_taken; > > } > > > > +static int > > +mem_cgroup_need_reclaim(struct mem_cgroup *mem) > > +{ > > + struct res_counter * const cnt = &mem->res; > > + int doreclaim; > > + unsigned long flags; > > + > > + /* XXX should be in res_counter */ > > + /* XXX should not hardcode a watermark */ > > We could add the following API to resource counters > > res_counter_set_low_watermark > res_counter_set_high_watermark > res_counter_below_low_watermark > res_counter_above_high_watermark > > and add > > low_watermark > high_watermark > > members to the resource group. We could push out data > upto the low watermark from the cgroup. it sounds fine to me. > > +static void > > +mem_cgroup_reclaim(struct work_struct *work) > > +{ > > + struct mem_cgroup * const mem = > > + container_of(work, struct mem_cgroup, reclaim_work); > > + int batch_count = 128; /* XXX arbitrary */ > > + > > + for (; batch_count > 0; batch_count--) { > > + if (!mem_cgroup_need_reclaim(mem)) > > + break; > > + /* > > + * XXX try_to_free_foo is not a correct mechanism to > > + * use here. eg. ALLOCSTALL counter > > + * revisit later. > > + */ > > + if (!try_to_free_mem_cgroup_pages(mem, GFP_KERNEL)) > > We could make try_to_free_mem_cgroup_pages, batch aware and pass that > in scan_control. in the comment above, i meant that it might be better to introduce something like balance_pgdat rather than using try_to_free_mem_cgroup_pages. with the current design of cgroup lru lists, probably it doesn't matter much except statistics, tho. YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2007-10-22T23:44:30-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: hi, > Can we potentially avoid direct reclaim and sleep if the charge is exceeded > and let the background reclaim do the job and wake us up? yes, but i left it for now because direct reclaim has its own benefits. YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2007-10-22T23:45:23-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: > > We could add the following API to resource counters > > > > res_counter_set_low_watermark > > res_counter_set_high_watermark > > res_counter_below_low_watermark > > res_counter_above_high_watermark > > > > and add > > > > low_watermark > > high_watermark > > > > members to the resource group. We could push out data > > upto the low watermark from the cgroup. i implemented something like that. (and rebased to 2.6.24-rc2-mm1.) what's the best way to expose watermarks to userland is an open question. i took the simplest way for now. do you have any suggestions? YAMAMOTO Takashi --- ./include/linux/res_counter.h.orig 2007-11-14 15:57:31.000000000 +0900 +++ ./include/linux/res_counter.h 2007-11-14 16:03:24.000000000 +0900 @@ -32,6 +32,13 @@ struct res_counter { * the number of unsuccessful attempts to consume the resource */ unsigned long long failcnt; + + /* + * watermarks + */ + unsigned long long high_watermark; + unsigned long long low_watermark; + /* * the lock to protect all of the above. * the routines below consider this to be IRQ-safe @@ -66,6 +73,8 @@ enum { RES_USAGE, RES_LIMIT, RES_FAILCNT, + RES_HIGH_WATERMARK, + RES_LOW_WATERMARK, }; /* @@ -124,4 +133,26 @@ static inline bool res_counter_check_und return ret; } +static inline bool res_counter_below_low_watermark(struct res_counter *cnt) +{ + bool ret; + unsigned long flags; + + spin_lock_irqsave(&cnt->lock, flags); + ret = cnt->usage < cnt->low_watermark; + spin_unlock_irqrestore(&cnt->lock, flags); + return ret; +} + +static inline bool res_counter_above_high_watermark(struct res_counter *cnt) +{ + bool ret; + unsigned long flags; + + spin_lock_irqsave(&cnt->lock, flags); + ret = cnt->usage > cnt->high_watermark; + spin_unlock_irqrestore(&cnt->lock, flags); + return ret; +} + #endif --- ./kernel/res_counter.c.orig 2007-11-14 15:57:31.000000000 +0900 +++ ./kernel/res_counter.c 2007-11-14 16:03:24.000000000 +0900 @@ -17,6 +17,8 @@ void res_counter_init(struct res_counter { spin_lock_init(&counter->lock);…
creator: yamamoto
date: 2007-11-15T06:16:02-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: > > > We could add the following API to resource counters > > > > > > res_counter_set_low_watermark > > > res_counter_set_high_watermark > > > res_counter_below_low_watermark > > > res_counter_above_high_watermark > > > > > > and add > > > > > > low_watermark > > > high_watermark > > > > > > members to the resource group. We could push out data > > > upto the low watermark from the cgroup. > > i implemented something like that. (and rebased to 2.6.24-rc2-mm1.) > > what's the best way to expose watermarks to userland is an open question. > i took the simplest way for now. do you have any suggestions? > > YAMAMOTO Takashi here's a new version. changes from the previous: - rebase to linux-2.6.24-rc2-mm1 + kamezawa patchset. - create workqueue when setting high watermark, rather than cgroup creation which is earlier on boot. YAMAMOTO Takashi Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp> --- --- linux-2.6.24-rc2-mm1-kame-pd/include/linux/res_counter.h.BACKUP 2007-11-14 16:05:48.000000000 +0900 +++ linux-2.6.24-rc2-mm1-kame-pd/include/linux/res_counter.h 2007-11-22 15:14:32.000000000 +0900 @@ -32,6 +32,13 @@ struct res_counter { * the number of unsuccessful attempts to consume the resource */ unsigned long long failcnt; + + /* + * watermarks + */ + unsigned long long high_watermark; + unsigned long long low_watermark; + /* * the lock to protect all of the above. * the routines below consider this to be IRQ-safe @@ -66,6 +73,8 @@ enum { RES_USAGE, RES_LIMIT, RES_FAILCNT, + RES_HIGH_WATERMARK, + RES_LOW_WATERMARK, }; /* @@ -124,4 +133,26 @@ static inline bool res_counter_check_und return ret; } +static inline bool res_counter_below_low_watermark(struct res_counter *cnt) +{ + bool ret; + unsigned long flags; + + spin_lock_irqsave(&cnt->lock, flags); + ret = cnt->usage < cnt->low_watermark; + spin_unlock_irqrestore(&cnt->lock, flags); + return ret; +} + +static inline bool res_counter_above_high_watermark(struct res_counter *cnt) +{ + bool ret; + unsigned long flag…
creator: yamamoto
date: 2007-11-22T08:57:33-00:00

Re: Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: >here's a new version. > Thank you. I'll review and try to merge yours in the next week, Regards, -Kame _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: KAMEZAWA Hiroyuki
date: 2007-11-22T13:33:13-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: YAMAMOTO Takashi wrote: > changes from the previous: > - rebase to linux-2.6.24-rc2-mm1 + kamezawa patchset. > - create workqueue when setting high watermark, rather than cgroup creation > which is earlier on boot. > > YAMAMOTO Takashi > > > Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp> > --- > > --- linux-2.6.24-rc2-mm1-kame-pd/include/linux/res_counter.h.BACKUP 2007-11-14 16:05:48.000000000 +0900 > +++ linux-2.6.24-rc2-mm1-kame-pd/include/linux/res_counter.h 2007-11-22 15:14:32.000000000 +0900 > @@ -32,6 +32,13 @@ struct res_counter { > * the number of unsuccessful attempts to consume the resource > */ > unsigned long long failcnt; > + > + /* > + * watermarks > + */ > + unsigned long long high_watermark; > + unsigned long long low_watermark; > + > /* > * the lock to protect all of the above. > * the routines below consider this to be IRQ-safe > @@ -66,6 +73,8 @@ enum { > RES_USAGE, > RES_LIMIT, > RES_FAILCNT, > + RES_HIGH_WATERMARK, > + RES_LOW_WATERMARK, > }; > > /* > @@ -124,4 +133,26 @@ static inline bool res_counter_check_und > return ret; > } > > +static inline bool res_counter_below_low_watermark(struct res_counter *cnt) > +{ > + bool ret; > + unsigned long flags; > + > + spin_lock_irqsave(&cnt->lock, flags); > + ret = cnt->usage < cnt->low_watermark; > + spin_unlock_irqrestore(&cnt->lock, flags); > + return ret; > +} > + > +static inline bool res_counter_above_high_watermark(struct res_counter *cnt) > +{ > + bool ret; > + unsigned long flags; > + > + spin_lock_irqsave(&cnt->lock, flags); > + ret = cnt->usage > cnt->high_watermark; > + spin_unlock_irqrestore(&cnt->lock, flags); > + return ret; > +} > + > #endif > --- linux-2.6.24-rc2-mm1-kame-pd/kernel/res_counter.c.BACKUP 2007-11-14 16:05:52.000000000 +0900 > +++ linux-2.6.24-rc2-mm1-kame-pd/kernel/res_counter.c 2007-11-22 15:14:32.000000000 +0900 > @@ -17,6 +17,8 @@ void res_counter_init(struct res_counter > { > spin_lock_init(&counter->lock); > counter->limit = (unsigned long long)LLONG_MAX; > …
creator: Balbir Singh
date: 2007-11-23T03:46:12-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: hi, > > --- linux-2.6.24-rc2-mm1-kame-pd/kernel/res_counter.c.BACKUP 2007-11-14 16:05:52.000000000 +0900 > > +++ linux-2.6.24-rc2-mm1-kame-pd/kernel/res_counter.c 2007-11-22 15:14:32.000000000 +0900 > > @@ -17,6 +17,8 @@ void res_counter_init(struct res_counter > > { > > spin_lock_init(&counter->lock); > > counter->limit = (unsigned long long)LLONG_MAX; > > + counter->high_watermark = (unsigned long long)LLONG_MAX; > > + counter->low_watermark = (unsigned long long)LLONG_MAX; > > Should low watermark also be LLONG_MAX? what else do you suggest? 0? currently it doesn't matter much because low_watermark is not used at all as far as high_watermark is LLONG_MAX. > > +static void > > +mem_cgroup_reclaim(struct work_struct *work) > > +{ > > + struct mem_cgroup * const mem = > > + container_of(work, struct mem_cgroup, reclaim_work); > > + int batch_count = 128; /* XXX arbitrary */ > > Could we define and use something like MEM_CGROUP_BATCH_COUNT for now? > Later we could consider and see if it needs to be tunable. numbers are > hard to read in code. although i don't think it makes sense, i can do so if you prefer. > > + > > + for (; batch_count > 0; batch_count--) { > > + if (res_counter_below_low_watermark(&mem->res)) > > + break; > > Shouldn't we also check to see that we start reclaim in background only > when we are above the high watermark? i don't understand what you mean. can you explain? highwatermark is checked by mem_cgroup_charge_common before waking these threads. > I'll start some tests on these patches. thanks. YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2007-11-26T02:47:10-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: YAMAMOTO Takashi wrote: > hi, > >>> --- linux-2.6.24-rc2-mm1-kame-pd/kernel/res_counter.c.BACKUP 2007-11-14 16:05:52.000000000 +0900 >>> +++ linux-2.6.24-rc2-mm1-kame-pd/kernel/res_counter.c 2007-11-22 15:14:32.000000000 +0900 >>> @@ -17,6 +17,8 @@ void res_counter_init(struct res_counter >>> { >>> spin_lock_init(&counter->lock); >>> counter->limit = (unsigned long long)LLONG_MAX; >>> + counter->high_watermark = (unsigned long long)LLONG_MAX; >>> + counter->low_watermark = (unsigned long long)LLONG_MAX; >> Should low watermark also be LLONG_MAX? > > what else do you suggest? 0? Something invalid or a good default value. I think LLONG_MAX is good for now, that ensures that no background reclaim happens till the administrator sets it up. > currently it doesn't matter much because low_watermark is not used at all > as far as high_watermark is LLONG_MAX. > Don't we use by checking res_counter_below_low_watermark()? >>> +static void >>> +mem_cgroup_reclaim(struct work_struct *work) >>> +{ >>> + struct mem_cgroup * const mem = >>> + container_of(work, struct mem_cgroup, reclaim_work); >>> + int batch_count = 128; /* XXX arbitrary */ >> Could we define and use something like MEM_CGROUP_BATCH_COUNT for now? >> Later we could consider and see if it needs to be tunable. numbers are >> hard to read in code. > > although i don't think it makes sense, i can do so if you prefer. > Using numbers like 128 make the code unreadable. I prefer something like MEM_CGROUP_BATCH_COUNT since its more readable than 128. If we ever propagate batch_count to other dependent functions, I'd much rather do it with a well defined name. >>> + >>> + for (; batch_count > 0; batch_count--) { >>> + if (res_counter_below_low_watermark(&mem->res)) >>> + break; >> Shouldn't we also check to see that we start reclaim in background only >> when we are above the high watermark? > > i don't understand what you mean. can you explain? > highwatermark is checked by mem_cgroup_charge_common before waking > these t…
creator: Balbir Singh
date: 2007-11-26T03:00:19-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: > > currently it doesn't matter much because low_watermark is not used at all > > as far as high_watermark is LLONG_MAX. > > > > Don't we use by checking res_counter_below_low_watermark()? yes, but only when we get above highwatermark. YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2007-11-26T03:12:53-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: Balbir Singh wrote: > YAMAMOTO Takashi wrote: >>>> + int batch_count = 128; /* XXX arbitrary */ >>> Could we define and use something like MEM_CGROUP_BATCH_COUNT for now? >>> Later we could consider and see if it needs to be tunable. numbers are >>> hard to read in code. >> although i don't think it makes sense, i can do so if you prefer. >> > > Using numbers like 128 make the code unreadable. I prefer something > like MEM_CGROUP_BATCH_COUNT since its more readable than 128. If we ever > propagate batch_count to other dependent functions, I'd much rather do > it with a well defined name. > I just checked we already have FORCE_UNCHARGE_BATCH, we could just rename and re-use it. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-11-26T03:56:05-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: YAMAMOTO Takashi wrote: >> I'll start some tests on these patches. > > thanks. > I tried testing, but the patch failed to apply. I think thats because it was ported on top of the NUMA patches by KAMEZAWA-San. I'll rebase and test. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: Balbir Singh
date: 2007-11-26T04:09:04-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: > Balbir Singh wrote: > > YAMAMOTO Takashi wrote: > >>>> + int batch_count = 128; /* XXX arbitrary */ > >>> Could we define and use something like MEM_CGROUP_BATCH_COUNT for now? > >>> Later we could consider and see if it needs to be tunable. numbers are > >>> hard to read in code. > >> although i don't think it makes sense, i can do so if you prefer. > >> > > > > Using numbers like 128 make the code unreadable. I prefer something > > like MEM_CGROUP_BATCH_COUNT since its more readable than 128. If we ever > > propagate batch_count to other dependent functions, I'd much rather do > > it with a well defined name. > > > > I just checked we already have FORCE_UNCHARGE_BATCH, we could just > rename and re-use it. i don't think it's a good idea to use a single constant for completely different things. YAMAMOTO Takashi _______________________________________________ Containers mailing list Containers@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers
creator: yamamoto
date: 2007-11-26T22:43:58-00:00

Re: [RFC] [PATCH] memory controller background reclamation
type: item
description: > Using numbers like 128 make the code unreadable. I prefer something > like MEM_CGROUP_BATCH_COUNT since its more readable than 128. If we ever > propagate batch_count to other dependent functions, I'd much rather do > it with a well defined name. here's a new version. changes from the previous: - define a constant. (MEM_CGROUP_BG_RECLAIM_BATCH_COUNT) no functional changes. - don't increment ALLOCSTALL vm event for mem cgroup because it isn't appropriate esp. for background reclamation. introduce MEM_CGROUP_STAT_ALLOCSTALL instead. (its value is same as memory.failcnt unless GFP_ATOMIC.) YAMAMOTO Takashi Signed-off-by: YAMAMOTO Takashi <yamamoto@valinux.co.jp> --- --- linux-2.6.24-rc2-mm1-kame-pd/include/linux/res_counter.h.BACKUP 2007-11-14 16:05:48.000000000 +0900 +++ linux-2.6.24-rc2-mm1-kame-pd/include/linux/res_counter.h 2007-11-22 15:14:32.000000000 +0900 @@ -32,6 +32,13 @@ struct res_counter { * the number of unsuccessful attempts to consume the resource */ unsigned long long failcnt; + + /* + * watermarks + */ + unsigned long long high_watermark; + unsigned long long low_watermark; + /* * the lock to protect all of the above. * the routines below consider this to be IRQ-safe @@ -66,6 +73,8 @@ enum { RES_USAGE, RES_LIMIT, RES_FAILCNT, + RES_HIGH_WATERMARK, + RES_LOW_WATERMARK, }; /* @@ -124,4 +133,26 @@ static inline bool res_counter_check_und return ret; } +static inline bool res_counter_below_low_watermark(struct res_counter *cnt) +{ + bool ret; + unsigned long flags; + + spin_lock_irqsave(&cnt->lock, flags); + ret = cnt->usage < cnt->low_watermark; + spin_unlock_irqrestore(&cnt->lock, flags); + return ret; +} + +static inline bool res_counter_above_high_watermark(struct res_counter *cnt) +{ + bool ret; + unsigned long flags; + + spin_lock_irqsave(&cnt->lock, flags); + ret = cnt->usage > cnt->high_watermark; + spin_unlock_irqrestore(&cnt->lock, flags); + return ret; +} + #endif --- linux-2.6.24-rc2-mm1-kame-pd/kernel/res_counter.c.BACKUP 2007-11-14 16:05:5…
creator: yamamoto
date: 2007-11-26T23:46:19-00:00