linux-toradex.git/kernel/res_counter.c, branch v3.14.3

memcg: reduce function dereference

2013-09-12T22:38:02+00:00

This function dereferences res far too often, so optimize it.

Signed-off-by: Sha Zhengju 
Signed-off-by: Qiang Huang 
Acked-by: Michal Hocko 
Cc: Daisuke Nishimura 
Cc: Jeff Liu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: avoid overflow caused by PAGE_ALIGN

2013-09-12T22:38:02+00:00

Since PAGE_ALIGN is aligning up(the next page boundary), so after
PAGE_ALIGN, the value might be overflow, such as write the MAX value to
*.limit_in_bytes.

  $ cat /cgroup/memory/memory.limit_in_bytes
  18446744073709551615

  # echo 18446744073709551615 > /cgroup/memory/memory.limit_in_bytes
  bash: echo: write error: Invalid argument

Some user programs might depend on such behaviours(like libcg, we read
the value in snapshot, then use the value to reset cgroup later), and
that will cause confusion.  So we need to fix it.

Signed-off-by: Sha Zhengju 
Signed-off-by: Qiang Huang 
Acked-by: Michal Hocko 
Cc: Daisuke Nishimura 
Cc: Jeff Liu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: rename RESOURCE_MAX to RES_COUNTER_MAX

2013-09-12T22:38:02+00:00

RESOURCE_MAX is far too general name, change it to RES_COUNTER_MAX.

Signed-off-by: Sha Zhengju 
Signed-off-by: Qiang Huang 
Acked-by: Michal Hocko 
Cc: Daisuke Nishimura 
Cc: Jeff Liu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

res_counter: return amount of charges after res_counter_uncharge()

2012-12-18T23:02:12+00:00

It is useful to know how many charges are still left after a call to
res_counter_uncharge.  While it is possible to issue a res_counter_read
after uncharge, this can be racy.

If we need, for instance, to take some action when the counters drop down
to 0, only one of the callers should see it.  This is the same semantics
as the atomic variables in the kernel.

Since the current return value is void, we don't need to worry about
anything breaking due to this change: nobody relied on that, and only
users appearing from now on will be checking this value.

Signed-off-by: Glauber Costa 
Reviewed-by: Michal Hocko 
Acked-by: Kamezawa Hiroyuki 
Acked-by: David Rientjes 
Cc: Johannes Weiner 
Cc: Suleiman Souhlal 
Cc: Tejun Heo 
Cc: Christoph Lameter 
Cc: Frederic Weisbecker 
Cc: Greg Thelen 
Cc: JoonSoo Kim 
Cc: Mel Gorman 
Cc: Pekka Enberg 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

res_counter: delete res_counter_write()

2012-12-13T01:38:33+00:00

Since commit 628f42355389 ("memcg: limit change shrink usage") both
res_counter_write() and write_strategy_fn have been unused.  This patch
deletes them both.

Signed-off-by: Greg Thelen 
Cc: Glauber Costa 
Cc: Tejun Heo 
Acked-by: KAMEZAWA Hiroyuki 
Cc: Frederic Weisbecker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rescounters: add res_counter_uncharge_until()

2012-05-29T23:22:27+00:00

When killing a res_counter which is a child of other counter, we need to
do

	res_counter_uncharge(child, xxx)
	res_counter_charge(parent, xxx)

This is not atomic and wastes CPU.  This patch adds
res_counter_uncharge_until().  This function's uncharge propagates to
ancestors until specified res_counter.

	res_counter_uncharge_until(child, parent, xxx)

Now the operation is atomic and efficient.

Signed-off-by: Frederic Weisbecker 
Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Aneesh Kumar K.V 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Ying Han 
Cc: Glauber Costa 
Reviewed-by: Tejun Heo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

res_counter: Account max_usage when calling res_counter_charge_nofail()

2012-04-27T21:37:09+00:00

Updating max_usage is something one would expect when we reach
a new maximum usage value even when we do this by forcing through
the limit with res_counter_charge_nofail().

(Whether we want to account failcnt when we force through the limit
is another debate).

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Tejun Heo 
Acked-by: KAMEZAWA Hiroyuki 
Acked-by: Glauber Costa 
Acked-by: Kirill A. Shutemov 
Cc: Li Zefan

res_counter: Merge res_counter_charge and res_counter_charge_nofail

2012-04-27T21:36:45+00:00

These two functions do almost the same thing and duplicate some code.
Merge their implementation into a single common function.
res_counter_charge_locked() takes one more parameter but it doesn't seem
to be used outside res_counter.c yet anyway.

There is no (intended) change in the behaviour.

Signed-off-by: Frederic Weisbecker 
Signed-off-by: Tejun Heo 
Acked-by: KAMEZAWA Hiroyuki 
Acked-by: Glauber Costa 
Acked-by: Kirill A. Shutemov 
Cc: Li Zefan

net: introduce res_counter_charge_nofail() for socket allocations

2012-01-22T20:08:46+00:00

There is a case in __sk_mem_schedule(), where an allocation
is beyond the maximum, but yet we are allowed to proceed.
It happens under the following condition:

	sk->sk_wmem_queued + size >= sk->sk_sndbuf

The network code won't revert the allocation in this case,
meaning that at some point later it'll try to do it. Since
this is never communicated to the underlying res_counter
code, there is an inbalance in res_counter uncharge operation.

I see two ways of fixing this:

1) storing the information about those allocations somewhere
   in memcg, and then deducting from that first, before
   we start draining the res_counter,
2) providing a slightly different allocation function for
   the res_counter, that matches the original behavior of
   the network code more closely.

I decided to go for #2 here, believing it to be more elegant,
since #1 would require us to do basically that, but in a more
obscure way.

Signed-off-by: Glauber Costa 
Cc: KAMEZAWA Hiroyuki 
Cc: Johannes Weiner 
Cc: Michal Hocko 
CC: Tejun Heo 
CC: Li Zefan 
CC: Laurent Chavey 
Acked-by: Tejun Heo 
Signed-off-by: David S. Miller

resource cgroups: remove bogus cast

2011-12-13T15:43:08+00:00

The memparse() function already accepts const char * as the parsing string.

Signed-off-by: Davidlohr Bueso 
Acked-by: Pavel Emelyanov 
Signed-off-by: Tejun Heo