Re: [PATCH V3 2/7] Add per memcg reclaim watermarks

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Wed, 13 Apr 2011 11:40:26 -0700
Ying Han <yinghan@google.com> wrote:

> On Wed, Apr 13, 2011 at 1:25 AM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@jp.fujitsu.com> wrote:
> 
> > On Wed, 13 Apr 2011 00:03:02 -0700
> > Ying Han <yinghan@google.com> wrote:

> > > +static void setup_per_memcg_wmarks(struct mem_cgroup *mem)
> > > +{
> > > +     u64 limit;
> > > +     unsigned long wmark_ratio;
> > > +
> > > +     wmark_ratio = get_wmark_ratio(mem);
> > > +     limit = mem_cgroup_get_limit(mem);
> > > +     if (wmark_ratio == 0) {
> > > +             res_counter_set_low_wmark_limit(&mem->res, limit);
> > > +             res_counter_set_high_wmark_limit(&mem->res, limit);
> > > +     } else {
> > > +             unsigned long low_wmark, high_wmark;
> > > +             unsigned long long tmp = (wmark_ratio * limit) / 100;
> >
> > could you make this ratio as /1000 ? percent is too big.
> > And, considering misc. cases, I don't think having per-memcg "ratio" is
> > good.
> >
> > How about following ?
> >
> >  - provides an automatic wmark without knob. 0 wmark is okay, for me.
> >  - provides 2 intrerfaces as
> >        memory.low_wmark_distance_in_bytes,  # == hard_limit - low_wmark.
> >        memory.high_wmark_in_bytes,          # == hard_limit - high_wmark.
> >   (need to add sanity check into set_limit.)
> >
> > Hmm. Making the wmarks tunable individually make sense to me. One problem I
> do notice is that making the hard_limit as the bar might not working well on
> over-committing system. Which means the per-cgroup background reclaim might
> not be triggered before global memory pressure. Ideally, we would like to do
> more per-cgroup reclaim before triggering global memory pressure.
> 
hmm.

> How about adding the two APIs but make the calculation based on:
> 
> -- by default, the wmarks are equal to hard_limit. ( no background reclaim)

ok.

> -- provides 2 intrerfaces as
>        memory.low_wmark_distance_in_bytes,  # == min(hard_limit, soft_limit)
> - low_wmark.
>        memory.high_wmark_in_bytes,          # == min(hard_limit, soft_limit)
> - high_wmark.
> 

Hmm, with that interface, soflimit=0(or some low value) will disable background
reclaim. (IOW, all memory will be reclaimed.)

IMHO, we don't need take care of softlimit v.s. high/low wmark. It's userland job.
And we cannot know global relcaim's run via memcg' memory uasge....because of
nodes and zones. I think low/high wmark should work against hard_limit.


> >
> > In this patch, kswapd runs while
> >
> >        high_wmark < usage < low_wmark
> > ?
> >
> > Hmm, I like
> >        low_wmark < usage < high_wmark.
> >
> > ;) because it's kswapd.
> >
> > I adopt the same concept of global kswapd where low_wmark triggers the
> kswpd and hight_wmark stop it. And here, we have
> 
> (limit - high_wmark) < free < (limit - low_wmark)
> 

Hm, ok. please add comment somewhere.

Thanks,
-Kame







--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>