Thread (26 messages) 26 messages, 3 authors, 2011-07-22

Re: [PATCH 1/4] memcg: do not try to drain per-cpu caches without pages

From: Michal Hocko <hidden>
Date: 2011-07-22 09:19:41
Also in: lkml

On Fri 22-07-11 08:44:13, KAMEZAWA Hiroyuki wrote:
On Thu, 21 Jul 2011 13:36:06 +0200
Michal Hocko [off-list ref] wrote:
quoted
On Thu 21-07-11 19:12:50, KAMEZAWA Hiroyuki wrote:
quoted
On Thu, 21 Jul 2011 09:38:00 +0200
Michal Hocko [off-list ref] wrote:
quoted
drain_all_stock_async tries to optimize a work to be done on the work
queue by excluding any work for the current CPU because it assumes that
the context we are called from already tried to charge from that cache
and it's failed so it must be empty already.
While the assumption is correct we can do it by checking the current
number of pages in the cache. This will also reduce a work on other CPUs
with an empty stock.

Signed-off-by: Michal Hocko <redacted>

At the first look, when a charge against TransParentHugepage() goes
into the reclaim routine, stock->nr_pages != 0 and this will
call additional kworker.
True. We will drain a charge which could be used by other allocations
in the meantime so we have a good chance to reclaim less. But how big
problem is that?
I mean I can add a new parameter that would force checking the current
cpu but it doesn't look nice. I cannot add that condition
unconditionally because the code will be shared with the sync path in
the next patch and that one needs to drain _all_ cpus.

What would you suggest?
By 2 methods

 - just check nr_pages. 
Not sure I understand which nr_pages you mean. The one that comes from
the charging path or stock->nr_pages?
If you mean the first one then we do not have in the reclaim path where
we call drain_all_stock_async.
 - drain "local stock" without calling schedule_work(). It's fast.
but there is nothing to be drained locally in the paths where we call
drain_all_stock_async... Or do you mean that drain_all_stock shouldn't
use work queue at all?
Thanks,
-Kame
-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help