On Wed, 13 Apr 2011 11:40:26 -0700
Ying Han <yinghan@xxxxxxxxxx> wrote:
> On Wed, Apr 13, 2011 at 1:25 AM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
>
> > On Wed, 13 Apr 2011 00:03:02 -0700
> > Ying Han <yinghan@xxxxxxxxxx> 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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>