Re: [PATCH 5/5] Memory controller soft limit reclaim on contention (v7)

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-23 13:20:45]:

> On Mon, 23 Mar 2009 09:42:53 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> 
> > > Even if order > 0, mem_cgroup_try_to_free_pages() may be able to recover
> > > the situation. Maybe it's better to allow lumpty-reclaim even when
> > > !scanning_global_lru().
> > > 
> > 
> > if order > 0, we let the global reclaim handler reclaim (scan global
> > LRU). I think the chance of success is higher through that path,
> > having said that I have not experimented with trying to allow
> > lumpy-reclaim from memory cgroup LRU's. I think that should be a
> > separate effort from this one.
> > 
> 
> But ignoring that will make the cost twice....
>

OK, lets fix it, but it as a separate effort and with data that shows
us the same.
 
> > > 
> > > > Even if we retry, we do a simple check for soft-limit-reclaim, if
> > > > there is really something to be reclaimed, we reclaim from there
> > > > first.
> > > > 
> > > That means you reclaim memory twice ;) 
> > > AFAIK,
> > >   - fork() -> task_struct/stack
> > >     page table in x86 PAE mode
> > > requires order-1 pages very frequently and this "call twice" approach will kill
> > > the application peformance very effectively.
> > 
> > Yes, it would if this was the only way to allocate pages. But look at
> > reality, with kswapd running in the background, how frequently do you
> > expect to hit the reclaim path. Could you clarify what you mean by
> > order-1 (2^1), if so soft limit reclaim is not invoked and it should
> > not hurt performance. What am I missing?
> > 
> Hmm, maybe running hackbench under memory pressure will tell the answer.
> Anyway, plz get Ack from people for memory management.
> Rik or Mel or Christoph or Nick or someone.
>

Rik is on the cc and is linux-mm. I hope they'll look at it.
 
> 
> > > 
> > > > >                if (!did_some_progress)
> > > > >                     did_some_progress = try_to_free_pages(zonelist, order, gfp_mask);
> > > > >         }else
> > > > >                     did_some_progress = try_to_free_pages(zonelist, order, gfp_mask);
> > > > > 
> > > > > 
> > > > >         maybe a bit more concervative.
> > > > > 
> > > > > 
> > > > >         And I wonder "nodemask" should be checked or not..
> > > > >         softlimit reclaim doesn't seem to work well with nodemask...
> > > > 
> > > > Doesn't the zonelist take care of nodemask?
> > > > 
> > > 
> > > Not sure, but I think, no check. hmm BUG in vmscan.c ?
> > > 
> > 
> > The zonelist is built using policy_zonelist, that handles nodemask as
> > well. That should keep the zonelist and nodemask in sync.. no?
> > 
> 
> I already sent a patch.

I've seen it, the basic assumption of the patch is that

policy_zonelist() and for_each_zone_zonelist_nodemask() where nodemask
is derived from policy_nodemask() give different results.. correct?

-- 
	Balbir

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>