01 Aug, 2013

2 commits

• 33cb876e9   vmpressure: make sure there are no events queued after memcg is offlined ... Browse Code »

  vmpressure is called synchronously from reclaim where the target_memcg
  is guaranteed to be alive but the eventfd is signaled from the work
  queue context. This means that memcg (along with vmpressure structure
  which is embedded into it) might go away while the work item is pending
  which would result in use-after-release bug.

  We have two possible ways how to fix this. Either vmpressure pins memcg
  before it schedules vmpr->work and unpin it in vmpressure_work_fn or
  explicitely flush the work item from the css_offline context (as
  suggested by Tejun).

  This patch implements the later one and it introduces vmpressure_cleanup
  which flushes the vmpressure work queue item item. It hooks into
  mem_cgroup_css_offline after the memcg itself is cleaned up.

  [akpm@linux-foundation.org: coding-style fixes]
  Signed-off-by: Michal Hocko
  Reported-by: Tejun Heo
  Cc: Anton Vorontsov
  Cc: Johannes Weiner
  Cc: KAMEZAWA Hiroyuki
  Cc: KOSAKI Motohiro
  Cc: Li Zefan
  Acked-by: Tejun Heo
  Signed-off-by: Andrew Morton
  Signed-off-by: Linus Torvalds

  Michal Hocko

  2013-08-01 05:41:04 +0800  
• 22f2020f8   vmpressure: change vmpressure::sr_lock to spinlock ... Browse Code »

  There is nothing that can sleep inside critical sections protected by
  this lock and those sections are really small so there doesn't make much
  sense to use mutex for them. Change the log to a spinlock

  Signed-off-by: Michal Hocko
  Reported-by: Tejun Heo
  Cc: Anton Vorontsov
  Cc: Johannes Weiner
  Cc: KAMEZAWA Hiroyuki
  Cc: KOSAKI Motohiro
  Cc: Li Zefan
  Reviewed-by: Tejun Heo
  Signed-off-by: Andrew Morton
  Signed-off-by: Linus Torvalds

  Michal Hocko

  2013-08-01 05:41:03 +0800  

30 Apr, 2013

1 commit

• 70ddf637e   memcg: add memory.pressure_level events ... Browse Code »

  With this patch userland applications that want to maintain the
  interactivity/memory allocation cost can use the pressure level
  notifications. The levels are defined like this:

  The "low" level means that the system is reclaiming memory for new
  allocations. Monitoring this reclaiming activity might be useful for
  maintaining cache level. Upon notification, the program (typically
  "Activity Manager") might analyze vmstat and act in advance (i.e.
  prematurely shutdown unimportant services).

  The "medium" level means that the system is experiencing medium memory
  pressure, the system might be making swap, paging out active file
  caches, etc. Upon this event applications may decide to further analyze
  vmstat/zoneinfo/memcg or internal memory usage statistics and free any
  resources that can be easily reconstructed or re-read from a disk.

  The "critical" level means that the system is actively thrashing, it is
  about to out of memory (OOM) or even the in-kernel OOM killer is on its
  way to trigger. Applications should do whatever they can to help the
  system. It might be too late to consult with vmstat or any other
  statistics, so it's advisable to take an immediate action.

  The events are propagated upward until the event is handled, i.e. the
  events are not pass-through. Here is what this means: for example you
  have three cgroups: A->B->C. Now you set up an event listener on
  cgroups A, B and C, and suppose group C experiences some pressure. In
  this situation, only group C will receive the notification, i.e. groups
  A and B will not receive it. This is done to avoid excessive
  "broadcasting" of messages, which disturbs the system and which is
  especially bad if we are low on memory or thrashing. So, organize the
  cgroups wisely, or propagate the events manually (or, ask us to
  implement the pass-through events, explaining why would you need them.)

  Performance wise, the memory pressure notifications feature itself is
  lightweight and does not require much of bookkeeping, in contrast to the
  rest of memcg features. Unfortunately, as of current memcg
  implementation, pages accounting is an inseparable part and cannot be
  turned off. The good news is that there are some efforts[1] to improve
  the situation; plus, implementing the same, fully API-compatible[2]
  interface for CONFIG_MEMCG=n case (e.g. embedded) is also a viable
  option, so it will not require any changes on the userland side.

  [1] http://permalink.gmane.org/gmane.linux.kernel.cgroups/6291
  [2] http://lkml.org/lkml/2013/2/21/454

  [akpm@linux-foundation.org: coding-style fixes]
  [akpm@linux-foundation.org: fix CONFIG_CGROPUPS=n warnings]
  Signed-off-by: Anton Vorontsov
  Acked-by: Kirill A. Shutemov
  Acked-by: KAMEZAWA Hiroyuki
  Cc: Tejun Heo
  Cc: David Rientjes
  Cc: Pekka Enberg
  Cc: Mel Gorman
  Cc: Glauber Costa
  Cc: Michal Hocko
  Cc: Luiz Capitulino
  Cc: Greg Thelen
  Cc: Leonid Moiseichuk
  Cc: KOSAKI Motohiro
  Cc: Minchan Kim
  Cc: Bartlomiej Zolnierkiewicz
  Cc: John Stultz
  Signed-off-by: Andrew Morton
  Signed-off-by: Linus Torvalds

  Anton Vorontsov

  2013-04-30 06:54:38 +0800