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: KAMEZAWA Hiroyuki <hidden>
Date: 2011-07-21 23:51:43
Also in: lkml

On Thu, 21 Jul 2011 13:36:06 +0200
Michal Hocko [off-list ref] wrote:
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. 
 - drain "local stock" without calling schedule_work(). It's fast.

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