On Wed, 20 Apr 2011 21:24:07 -0700
Ying Han <yinghan@xxxxxxxxxx> wrote:
> On Wed, Apr 20, 2011 at 9:00 PM, KAMEZAWA Hiroyuki <
> kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> > > > Two watermarks ("high_wmark", "low_wmark") are added to trigger the
> > > > background reclaim and stop it. The watermarks are calculated based
> > > > on the cgroup's limit_in_bytes.
> > >
> > > Which brings me to the next issue: making the watermarks configurable.
> > >
> > > You argued that having them adjustable from userspace is required for
> > > overcommitting the hardlimits and per-memcg kswapd reclaim not kicking
> > > in in case of global memory pressure. But that is only a problem
> > > because global kswapd reclaim is (apart from soft limit reclaim)
> > > unaware of memory control groups.
> > >
> > > I think the much better solution is to make global kswapd memcg aware
> > > (with the above mentioned round-robin reclaim scheduler), compared to
> > > adding new (and final!) kernel ABI to avoid an internal shortcoming.
> > >
> >
> > I don't think its a good idea to kick kswapd even when free memory is
> > enough.
> >
> > If memcg-kswapd implemted, I'd like to add auto-cgroup for memcg-kswapd and
> > limit its cpu usage because it works even when memory is not in-short.
> >
>
> How are we gonna isolate the memcg-kswapd cpu usage under the workqueue
> model?
>
Admin can limit the total cpu usage of memcg-kswapd. So, using private
workqueue model seems to make sense.
If background-reclaim uses up its cpu share, heavy worker memcg will hit
direct reclaim and need to consume its own cpu time. I think it's fair.
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>