linux-toradex.git/include/linux/res_counter.h, branch v3.12-rc5

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

memcg: correct RESOURCE_MAX to ULLONG_MAX

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

Current RESOURCE_MAX is ULONG_MAX, but the value we used to set resource
limit is unsigned long long, so we can set bigger value than that which is
strange.  The XXX_MAX should be reasonable max value, bigger than that
should be overflow.

Notice that this change will affect user output of default *.limit_in_bytes:
before change:

  $ cat /cgroup/memory/memory.limit_in_bytes
  9223372036854775807

after change:

  $ cat /cgroup/memory/memory.limit_in_bytes
  18446744073709551615

But it doesn't alter the API in term of input - we can still use "echo -1
> *.limit_in_bytes" to reset the numbers to "unlimited".

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

Merge branch 'for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup

2013-04-30T02:14:20+00:00

Pull cgroup updates from Tejun Heo:

 - Fixes and a lot of cleanups.  Locking cleanup is finally complete.
   cgroup_mutex is no longer exposed to individual controlelrs which
   used to cause nasty deadlock issues.  Li fixed and cleaned up quite a
   bit including long standing ones like racy cgroup_path().

 - device cgroup now supports proper hierarchy thanks to Aristeu.

 - perf_event cgroup now supports proper hierarchy.

 - A new mount option "__DEVEL__sane_behavior" is added.  As indicated
   by the name, this option is to be used for development only at this
   point and generates a warning message when used.  Unfortunately,
   cgroup interface currently has too many brekages and inconsistencies
   to implement a consistent and unified hierarchy on top.  The new flag
   is used to collect the behavior changes which are necessary to
   implement consistent unified hierarchy.  It's likely that this flag
   won't be used verbatim when it becomes ready but will be enabled
   implicitly along with unified hierarchy.

   The option currently disables some of broken behaviors in cgroup core
   and also .use_hierarchy switch in memcg (will be routed through -mm),
   which can be used to make very unusual hierarchy where nesting is
   partially honored.  It will also be used to implement hierarchy
   support for blk-throttle which would be impossible otherwise without
   introducing a full separate set of control knobs.

   This is essentially versioning of interface which isn't very nice but
   at this point I can't see any other options which would allow keeping
   the interface the same while moving towards hierarchy behavior which
   is at least somewhat sane.  The planned unified hierarchy is likely
   to require some level of adaptation from userland anyway, so I think
   it'd be best to take the chance and update the interface such that
   it's supportable in the long term.

   Maintaining the existing interface does complicate cgroup core but
   shouldn't put too much strain on individual controllers and I think
   it'd be manageable for the foreseeable future.  Maybe we'll be able
   to drop it in a decade.

Fix up conflicts (including a semantic one adding a new #include to ppc
that was uncovered by header the file changes) as per Tejun.

* 'for-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: (45 commits)
  cpuset: fix compile warning when CONFIG_SMP=n
  cpuset: fix cpu hotplug vs rebuild_sched_domains() race
  cpuset: use rebuild_sched_domains() in cpuset_hotplug_workfn()
  cgroup: restore the call to eventfd->poll()
  cgroup: fix use-after-free when umounting cgroupfs
  cgroup: fix broken file xattrs
  devcg: remove parent_cgroup.
  memcg: force use_hierarchy if sane_behavior
  cgroup: remove cgrp->top_cgroup
  cgroup: introduce sane_behavior mount option
  move cgroupfs_root to include/linux/cgroup.h
  cgroup: convert cgroupfs_root flag bits to masks and add CGRP_ prefix
  cgroup: make cgroup_path() not print double slashes
  Revert "cgroup: remove bind() method from cgroup_subsys."
  perf: make perf_event cgroup hierarchical
  cgroup: implement cgroup_is_descendant()
  cgroup: make sure parent won't be destroyed before its children
  cgroup: remove bind() method from cgroup_subsys.
  devcg: remove broken_hierarchy tag
  cgroup: remove cgroup_lock_is_held()
  ...

include/linux/res_counter.h needs errno.h

2013-03-13T22:21:44+00:00

alpha allmodconfig:

  In file included from mm/memcontrol.c:28:
  include/linux/res_counter.h: In function 'res_counter_set_limit':
  include/linux/res_counter.h:203: error: 'EBUSY' undeclared (first use in this function)
  include/linux/res_counter.h:203: error: (Each undeclared identifier is reported only once
  include/linux/res_counter.h:203: error: for each function it appears in.)

Cc: Kamezawa Hiroyuki 
Cc: Glauber Costa 
Cc: Tejun Heo 
Cc: Frederic Weisbecker 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

res_counter: remove include of cgroup.h from res_counter.h

2013-03-05T17:33:26+00:00

It's not needed at all.

Signed-off-by: Li Zefan 
Signed-off-by: Tejun Heo

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

rescounter: remove __must_check from res_counter_charge_nofail()

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

Since we will succeed with the allocation no matter what, there isn't a
need to use __must_check with it.  It can very well be optional.

Signed-off-by: Glauber Costa 
Signed-off-by: KAMEZAWA Hiroyuki 
Cc: Aneesh Kumar K.V 
Cc: Michal Hocko 
Cc: Johannes Weiner 
Cc: Frederic Weisbecker 
Cc: Ying Han 
Reviewed-by: Tejun Heo 
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: 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