1. 19 12月, 2012 8 次提交
    • G
      slab/slub: consider a memcg parameter in kmem_create_cache · 2633d7a0
      Glauber Costa 提交于
      Allow a memcg parameter to be passed during cache creation.  When the slub
      allocator is being used, it will only merge caches that belong to the same
      memcg.  We'll do this by scanning the global list, and then translating
      the cache to a memcg-specific cache
      
      Default function is created as a wrapper, passing NULL to the memcg
      version.  We only merge caches that belong to the same memcg.
      
      A helper is provided, memcg_css_id: because slub needs a unique cache name
      for sysfs.  Since this is visible, but not the canonical location for slab
      data, the cache name is not used, the css_id should suffice.
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Frederic Weisbecker <fweisbec@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2633d7a0
    • G
      slab/slub: struct memcg_params · ba6c496e
      Glauber Costa 提交于
      For the kmem slab controller, we need to record some extra information in
      the kmem_cache structure.
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Signed-off-by: NSuleiman Souhlal <suleiman@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Frederic Weisbecker <fweisbec@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba6c496e
    • G
      fork: protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs · 2ad306b1
      Glauber Costa 提交于
      Because those architectures will draw their stacks directly from the page
      allocator, rather than the slab cache, we can directly pass __GFP_KMEMCG
      flag, and issue the corresponding free_pages.
      
      This code path is taken when the architecture doesn't define
      CONFIG_ARCH_THREAD_INFO_ALLOCATOR (only ia64 seems to), and has
      THREAD_SIZE >= PAGE_SIZE.  Luckily, most - if not all - of the remaining
      architectures fall in this category.
      
      This will guarantee that every stack page is accounted to the memcg the
      process currently lives on, and will have the allocations to fail if they
      go over limit.
      
      For the time being, I am defining a new variant of THREADINFO_GFP, not to
      mess with the other path.  Once the slab is also tracked by memcg, we can
      get rid of that flag.
      
      Tested to successfully protect against :(){ :|:& };:
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Acked-by: NFrederic Weisbecker <fweisbec@redhat.com>
      Acked-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2ad306b1
    • G
      memcg: use static branches when code not in use · a8964b9b
      Glauber Costa 提交于
      We can use static branches to patch the code in or out when not used.
      
      Because the _ACTIVE bit on kmem_accounted is only set after the increment
      is done, we guarantee that the root memcg will always be selected for kmem
      charges until all call sites are patched (see memcg_kmem_enabled).  This
      guarantees that no mischarges are applied.
      
      Static branch decrement happens when the last reference count from the
      kmem accounting in memcg dies.  This will only happen when the charges
      drop down to 0.
      
      When that happens, we need to disable the static branch only on those
      memcgs that enabled it.  To achieve this, we would be forced to complicate
      the code by keeping track of which memcgs were the ones that actually
      enabled limits, and which ones got it from its parents.
      
      It is a lot simpler just to do static_key_slow_inc() on every child
      that is accounted.
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Frederic Weisbecker <fweisbec@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a8964b9b
    • G
      res_counter: return amount of charges after res_counter_uncharge() · 50bdd430
      Glauber Costa 提交于
      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: NGlauber Costa <glommer@parallels.com>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Frederic Weisbecker <fweisbec@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50bdd430
    • G
      mm: allocate kernel pages to the right memcg · 6a1a0d3b
      Glauber Costa 提交于
      When a process tries to allocate a page with the __GFP_KMEMCG flag, the
      page allocator will call the corresponding memcg functions to validate
      the allocation.  Tasks in the root memcg can always proceed.
      
      To avoid adding markers to the page - and a kmem flag that would
      necessarily follow, as much as doing page_cgroup lookups for no reason,
      whoever is marking its allocations with __GFP_KMEMCG flag is responsible
      for telling the page allocator that this is such an allocation at
      free_pages() time.  This is done by the invocation of
      __free_accounted_pages() and free_accounted_pages().
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: Rik van Riel <riel@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a1a0d3b
    • G
      memcg: kmem controller infrastructure · 7ae1e1d0
      Glauber Costa 提交于
      Introduce infrastructure for tracking kernel memory pages to a given
      memcg.  This will happen whenever the caller includes the flag
      __GFP_KMEMCG flag, and the task belong to a memcg other than the root.
      
      In memcontrol.h those functions are wrapped in inline acessors.  The idea
      is to later on, patch those with static branches, so we don't incur any
      overhead when no mem cgroups with limited kmem are being used.
      
      Users of this functionality shall interact with the memcg core code
      through the following functions:
      
      memcg_kmem_newpage_charge: will return true if the group can handle the
                                 allocation. At this point, struct page is not
                                 yet allocated.
      
      memcg_kmem_commit_charge: will either revert the charge, if struct page
                                allocation failed, or embed memcg information
                                into page_cgroup.
      
      memcg_kmem_uncharge_page: called at free time, will revert the charge.
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Frederic Weisbecker <fweisbec@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7ae1e1d0
    • G
      mm: add a __GFP_KMEMCG flag · 7a64bf05
      Glauber Costa 提交于
      This flag is used to indicate to the callees that this allocation is a
      kernel allocation in process context, and should be accounted to current's
      memcg.
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
      Acked-by: NRik van Riel <riel@redhat.com>
      Acked-by: NMel Gorman <mel@csn.ul.ie>
      Acked-by: NKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: NMichal Hocko <mhocko@suse.cz>
      Acked-by: NChristoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Suleiman Souhlal <suleiman@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Frederic Weisbecker <fweisbec@redhat.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: JoonSoo Kim <js1304@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7a64bf05
  2. 18 12月, 2012 21 次提交
  3. 17 12月, 2012 1 次提交
  4. 16 12月, 2012 2 次提交
  5. 15 12月, 2012 3 次提交
    • S
      block: discard granularity might not be power of 2 · 8dd2cb7e
      Shaohua Li 提交于
      In MD raid case, discard granularity might not be power of 2, for example, a
      4-disk raid5 has 3*chunk_size discard granularity. Correct the calculation for
      such cases.
      Reported-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NShaohua Li <shli@fusionio.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      8dd2cb7e
    • E
      drm/exynos: add fimc ipp driver · 16102edb
      Eunchul Kim 提交于
      FIMC is stand for Fully Interfactive Mobile Camera and
      supports image scaler/rotator/crop/flip/csc and input/output DMA operations
      and also supports writeback and display output operations.
      
      This driver is registered to IPP subsystem framework to be used by user side
      and user can control the FIMC hardware through some interfaces of IPP subsystem
      framework.
      
      Changelog v6:
      - fix build warning.
      
      Changelog v1 ~ v5:
      - add comments, code fixups and cleanups.
      Signed-off-by: NEunchul Kim <chulspro.kim@samsung.com>
      Signed-off-by: NJinyoung Jeon <jy0.jeon@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      16102edb
    • E
      drm/exynos: add ipp subsystem · cb471f14
      Eunchul Kim 提交于
      This patch adds Image Post Processing(IPP) support for exynos drm driver.
      
      IPP supports image scaler/rotator and input/output DMA operations
      using IPP subsystem framework to control FIMC, Rotator and GSC hardware
      and supports some user interfaces for user side.
      
      And each IPP-based drivers support Memory to Memory operations
      with various converting. And in case of FIMC hardware, it also supports
      Writeback and Display output operations through local path.
      
      Features:
      - Memory to Memory operation support.
      - Various pixel formats support.
      - Image scaling support.
      - Color Space Conversion support.
      - Image crop operation support.
      - Rotate operation support to 90, 180 or 270 degree.
      - Flip operation support to vertical, horizontal or both.
      - Writeback operation support to display blended image of FIMD fifo on screen
      
      A summary to IPP Subsystem operations:
      First of all, user should get property capabilities from IPP subsystem
      and set these properties to hardware registers for desired operations.
      The properties could be pixel format, position, rotation degree and
      flip operation.
      
      And next, user should set source and destination buffer data using
      DRM_EXYNOS_IPP_QUEUE_BUF ioctl command with gem handles to source and
      destinition buffers.
      
      And next, user can control user-desired hardware with desired operations
      such as play, stop, pause and resume controls.
      
      And finally, user can aware of dma operation completion and also get
      destination buffer that it contains user-desried result through dequeue
      command.
      
      IOCTL commands:
      - DRM_EXYNOS_IPP_GET_PROPERTY
        . get ipp driver capabilitis and id.
      - DRM_EXYNOS_IPP_SET_PROPERTY
        . set format, position, rotation, flip to source and destination buffers
      - DRM_EXYNOS_IPP_QUEUE_BUF
        . enqueue/dequeue buffer and make event list.
      - DRM_EXYNOS_IPP_CMD_CTRL
        . play/stop/pause/resume control.
      
      Event:
      - DRM_EXYNOS_IPP_EVENT
        . a event to notify dma operation completion to user side.
      
      Basic control flow:
      Open -> Get properties -> User choose desired IPP sub driver(FIMC, Rotator
      or GSCALER) -> Set Property -> Create gem handle -> Enqueue to source and
      destination buffers -> Command control(Play) -> Event is notified to User
      -> User gets destinition buffer complated -> (Enqueue to source and
      destination buffers -> Event is notified to User) * N -> Queue/Dequeue to
      source and destination buffers -> Command control(Stop) -> Free gem handle
      -> Close
      
      Changelog v1 ~ v5:
      - added comments, code fixups and cleanups.
      Signed-off-by: NEunchul Kim <chulspro.kim@samsung.com>
      Signed-off-by: NJinyoung Jeon <jy0.jeon@samsung.com>
      Signed-off-by: NInki Dae <inki.dae@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      cb471f14
  6. 14 12月, 2012 4 次提交
  7. 13 12月, 2012 1 次提交