1. 12 5月, 2013 1 次提交
  2. 01 5月, 2013 1 次提交
  3. 30 4月, 2013 2 次提交
    • D
      mm, hotplug: avoid compiling memory hotremove functions when disabled · 4edd7cef
      David Rientjes 提交于
      __remove_pages() is only necessary for CONFIG_MEMORY_HOTREMOVE.  PowerPC
      pseries will return -EOPNOTSUPP if unsupported.
      
      Adding an #ifdef causes several other functions it depends on to also
      become unnecessary, which saves in .text when disabled (it's disabled in
      most defconfigs besides powerpc, including x86).  remove_memory_block()
      becomes static since it is not referenced outside of
      drivers/base/memory.c.
      
      Build tested on x86 and powerpc with CONFIG_MEMORY_HOTREMOVE both enabled
      and disabled.
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Acked-by: NToshi Kani <toshi.kani@hp.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4edd7cef
    • A
      include/linux/memory.h: implement register_hotmemory_notifier() · f02c6968
      Andrew Morton 提交于
      When CONFIG_MEMORY_HOTPLUG=n, we don't want the memory-hotplug notifier
      handlers to be included in the .o files, for space reasons.
      
      The existing hotplug_memory_notifier() tries to handle this but testing
      with gcc-4.4.4 shows that it doesn't work - the hotplug functions are
      still present in the .o files.
      
      So implement a new register_hotmemory_notifier() which is a copy of
      register_hotcpu_notifier(), and which actually works as desired.
      hotplug_memory_notifier() and register_memory_notifier() callsites
      should be converted to use this new register_hotmemory_notifier().
      
      While we're there, let's repair the existing hotplug_memory_notifier():
      it simply stomps on the register_memory_notifier() return value, so
      well-behaved code cannot check for errors.  Apparently non of the
      existing callers were well-behaved :(
      
      Cc: Andrew Shewmaker <agshew@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f02c6968
  4. 13 12月, 2012 1 次提交
  5. 12 12月, 2012 1 次提交
    • L
      memory_hotplug: fix possible incorrect node_states[N_NORMAL_MEMORY] · d9713679
      Lai Jiangshan 提交于
      Currently memory_hotplug only manages the node_states[N_HIGH_MEMORY], it
      forgets to manage node_states[N_NORMAL_MEMORY].  This may cause
      node_states[N_NORMAL_MEMORY] to become incorrect.
      
      Example, if a node is empty before online, and we online a memory which is
      in ZONE_NORMAL.  And after online, node_states[N_HIGH_MEMORY] is correct,
      but node_states[N_NORMAL_MEMORY] is incorrect, the online code doesn't set
      the new online node to node_states[N_NORMAL_MEMORY].
      
      The same thing will happen when offlining (the offline code doesn't clear
      the node from node_states[N_NORMAL_MEMORY] when needed).  Some memory
      managment code depends node_states[N_NORMAL_MEMORY], so we have to fix up
      the node_states[N_NORMAL_MEMORY].
      
      We add node_states_check_changes_online() and
      node_states_check_changes_offline() to detect whether
      node_states[N_HIGH_MEMORY] and node_states[N_NORMAL_MEMORY] are changed
      while hotpluging.
      
      Also add @status_change_nid_normal to struct memory_notify, thus the
      memory hotplug callbacks know whether the node_states[N_NORMAL_MEMORY] are
      changed.  (We can add a @flags and reuse @status_change_nid instead of
      introducing @status_change_nid_normal, but it will add much more
      complexity in memory hotplug callback in every subsystem.  So introducing
      @status_change_nid_normal is better and it doesn't change the sematics of
      @status_change_nid)
      Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Minchan Kim <minchan.kim@gmail.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Cc: Rob Landley <rob@landley.net>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Cc: Greg Kroah-Hartman <gregkh@suse.de>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Wen Congyang <wency@cn.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d9713679
  6. 18 9月, 2012 1 次提交
    • J
      mm/ia64: fix a memory block size bug · 05cf9639
      Jianguo Wu 提交于
      I found following definition in include/linux/memory.h, in my IA64
      platform, SECTION_SIZE_BITS is equal to 32, and MIN_MEMORY_BLOCK_SIZE
      will be 0.
      
        #define MIN_MEMORY_BLOCK_SIZE     (1 << SECTION_SIZE_BITS)
      
      Because MIN_MEMORY_BLOCK_SIZE is int type and length of 32bits,
      so MIN_MEMORY_BLOCK_SIZE(1 << 32) will will equal to 0.
      Actually when SECTION_SIZE_BITS >= 31, MIN_MEMORY_BLOCK_SIZE will be wrong.
      This will cause wrong system memory infomation in sysfs.
      I think it should be:
      
        #define MIN_MEMORY_BLOCK_SIZE     (1UL << SECTION_SIZE_BITS)
      
      And "echo offline > memory0/state" will cause following call trace:
      
        kernel BUG at mm/memory_hotplug.c:885!
        sh[6455]: bugcheck! 0 [1]
        Pid: 6455, CPU 0, comm:                   sh
        psr : 0000101008526030 ifs : 8000000000000fa4 ip  : [<a0000001008c40f0>]    Not tainted (3.6.0-rc1)
        ip is at offline_pages+0x210/0xee0
        Call Trace:
          show_stack+0x80/0xa0
          show_regs+0x640/0x920
          die+0x190/0x2c0
          die_if_kernel+0x50/0x80
          ia64_bad_break+0x3d0/0x6e0
          ia64_native_leave_kernel+0x0/0x270
          offline_pages+0x210/0xee0
          alloc_pages_current+0x180/0x2a0
      Signed-off-by: NJianguo Wu <wujianguo@huawei.com>
      Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Reviewed-by: NMichal Hocko <mhocko@suse.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      05cf9639
  7. 22 12月, 2011 1 次提交
  8. 12 7月, 2011 1 次提交
  9. 04 2月, 2011 1 次提交
    • N
      memory hotplug: Update phys_index to [start|end]_section_nr · d3360164
      Nathan Fontenot 提交于
      Update the 'phys_index' property of a the memory_block struct to be
      called start_section_nr, and add a end_section_nr property.  The
      data tracked here is the same but the updated naming is more in line
      with what is stored here, namely the first and last section number
      that the memory block spans.
      
      The names presented to userspace remain the same, phys_index for
      start_section_nr and end_phys_index for end_section_nr, to avoid breaking
      anything in userspace.
      
      This also updates the node sysfs code to be aware of the new capability for
      a memory block to contain multiple memory sections and be aware of the memory
      block structure name changes (start_section_nr).  This requires an additional
      parameter to unregister_mem_sect_under_nodes so that we know which memory
      section of the memory block to unregister.
      Signed-off-by: NNathan Fontenot <nfont@austin.ibm.com>
      Reviewed-by: NRobin Holt <holt@sgi.com>
      Reviewed-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d3360164
  10. 23 10月, 2010 2 次提交
  11. 18 3月, 2010 1 次提交
    • H
      memory hotplug: allow setting of phys_device · bc32df00
      Heiko Carstens 提交于
      /sys/devices/system/memory/memoryX/phys_device is supposed to contain the
      number of the physical device that the corresponding piece of memory
      belongs to.
      
      In case a physical device should be replaced or taken offline for whatever
      reason it is necessary to set all corresponding memory pieces offline.
      The current implementation always sets phys_device to '0' and there is no
      way or hook to change that.  Seems like there was a plan to implement that
      but it wasn't finished for whatever reason.
      
      So add a weak function which architectures can override to actually set
      the phys_device from within add_memory_block().
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bc32df00
  12. 18 12月, 2009 1 次提交
    • R
      mm: Add notifier in pageblock isolation for balloon drivers · 925cc71e
      Robert Jennings 提交于
      Memory balloon drivers can allocate a large amount of memory which is not
      movable but could be freed to accomodate memory hotplug remove.
      
      Prior to calling the memory hotplug notifier chain the memory in the
      pageblock is isolated.  Currently, if the migrate type is not
      MIGRATE_MOVABLE the isolation will not proceed, causing the memory removal
      for that page range to fail.
      
      Rather than failing pageblock isolation if the migrateteype is not
      MIGRATE_MOVABLE, this patch checks if all of the pages in the pageblock,
      and not on the LRU, are owned by a registered balloon driver (or other
      entity) using a notifier chain.  If all of the non-movable pages are owned
      by a balloon, they can be freed later through the memory notifier chain
      and the range can still be isolated in set_migratetype_isolate().
      Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Brian King <brking@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Gerald Schaefer <geralds@linux.vnet.ibm.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      925cc71e
  13. 03 4月, 2009 1 次提交
  14. 06 3月, 2009 1 次提交
    • M
      tracing, Text Edit Lock - Architecture Independent Code · 0e39ac44
      Mathieu Desnoyers 提交于
      This is an architecture independant synchronization around kernel text
      modifications through use of a global mutex.
      
      A mutex has been chosen so that kprobes, the main user of this, can sleep
      during memory allocation between the memory read of the instructions it
      must replace and the memory write of the breakpoint.
      
      Other user of this interface: immediate values.
      
      Paravirt and alternatives are always done when SMP is inactive, so there
      is no need to use locks.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      LKML-Reference: <49B142D8.7020601@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0e39ac44
  15. 07 1月, 2009 1 次提交
    • G
      mm: show node to memory section relationship with symlinks in sysfs · c04fc586
      Gary Hade 提交于
      Show node to memory section relationship with symlinks in sysfs
      
      Add /sys/devices/system/node/nodeX/memoryY symlinks for all
      the memory sections located on nodeX.  For example:
      /sys/devices/system/node/node1/memory135 -> ../../memory/memory135
      indicates that memory section 135 resides on node1.
      
      Also revises documentation to cover this change as well as updating
      Documentation/ABI/testing/sysfs-devices-memory to include descriptions
      of memory hotremove files 'phys_device', 'phys_index', and 'state'
      that were previously not described there.
      
      In addition to it always being a good policy to provide users with
      the maximum possible amount of physical location information for
      resources that can be hot-added and/or hot-removed, the following
      are some (but likely not all) of the user benefits provided by
      this change.
      Immediate:
        - Provides information needed to determine the specific node
          on which a defective DIMM is located.  This will reduce system
          downtime when the node or defective DIMM is swapped out.
        - Prevents unintended onlining of a memory section that was
          previously offlined due to a defective DIMM.  This could happen
          during node hot-add when the user or node hot-add assist script
          onlines _all_ offlined sections due to user or script inability
          to identify the specific memory sections located on the hot-added
          node.  The consequences of reintroducing the defective memory
          could be ugly.
        - Provides information needed to vary the amount and distribution
          of memory on specific nodes for testing or debugging purposes.
      Future:
        - Will provide information needed to identify the memory
          sections that need to be offlined prior to physical removal
          of a specific node.
      
      Symlink creation during boot was tested on 2-node x86_64, 2-node
      ppc64, and 2-node ia64 systems.  Symlink creation during physical
      memory hot-add tested on a 2-node x86_64 system.
      Signed-off-by: NGary Hade <garyhade@us.ibm.com>
      Signed-off-by: NBadari Pulavarty <pbadari@us.ibm.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c04fc586
  16. 01 12月, 2008 1 次提交
  17. 29 4月, 2008 2 次提交
  18. 20 4月, 2008 1 次提交
  19. 19 4月, 2008 1 次提交
  20. 22 10月, 2007 2 次提交
    • Y
      memory hotplug: make kmem_cache_node for SLUB on memory online avoid panic · b9049e23
      Yasunori Goto 提交于
      Fix a panic due to access NULL pointer of kmem_cache_node at discard_slab()
      after memory online.
      
      When memory online is called, kmem_cache_nodes are created for all SLUBs
      for new node whose memory are available.
      
      slab_mem_going_online_callback() is called to make kmem_cache_node() in
      callback of memory online event.  If it (or other callbacks) fails, then
      slab_mem_offline_callback() is called for rollback.
      
      In memory offline, slab_mem_going_offline_callback() is called to shrink
      all slub cache, then slab_mem_offline_callback() is called later.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: locking fix]
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b9049e23
    • Y
      memory hotplug: rearrange memory hotplug notifier · 7b78d335
      Yasunori Goto 提交于
      Current memory notifier has some defects yet.  (Fortunately, nothing uses
      it.) This patch is to fix and rearrange for them.
      
        - Add information of start_pfn, nr_pages, and node id if node status is
          changes from/to memoryless node for callback functions.
          Callbacks can't do anything without those information.
        - Add notification going-online status.
          It is necessary for creating per node structure before the node's
          pages are available.
        - Move GOING_OFFLINE status notification after page isolation.
          It is good place for return memory like cache for callback,
          because returned page is not used again.
        - Make CANCEL events for rollingback when error occurs.
        - Delete MEM_MAPPING_INVALID notification. It will be not used.
        - Fix compile error of (un)register_memory_notifier().
      Signed-off-by: NYasunori Goto <y-goto@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b78d335
  21. 01 10月, 2006 1 次提交
  22. 28 3月, 2006 1 次提交
    • A
      [PATCH] Notifier chain update: API changes · e041c683
      Alan Stern 提交于
      The kernel's implementation of notifier chains is unsafe.  There is no
      protection against entries being added to or removed from a chain while the
      chain is in use.  The issues were discussed in this thread:
      
          http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2
      
      We noticed that notifier chains in the kernel fall into two basic usage
      classes:
      
      	"Blocking" chains are always called from a process context
      	and the callout routines are allowed to sleep;
      
      	"Atomic" chains can be called from an atomic context and
      	the callout routines are not allowed to sleep.
      
      We decided to codify this distinction and make it part of the API.  Therefore
      this set of patches introduces three new, parallel APIs: one for blocking
      notifiers, one for atomic notifiers, and one for "raw" notifiers (which is
      really just the old API under a new name).  New kinds of data structures are
      used for the heads of the chains, and new routines are defined for
      registration, unregistration, and calling a chain.  The three APIs are
      explained in include/linux/notifier.h and their implementation is in
      kernel/sys.c.
      
      With atomic and blocking chains, the implementation guarantees that the chain
      links will not be corrupted and that chain callers will not get messed up by
      entries being added or removed.  For raw chains the implementation provides no
      guarantees at all; users of this API must provide their own protections.  (The
      idea was that situations may come up where the assumptions of the atomic and
      blocking APIs are not appropriate, so it should be possible for users to
      handle these things in their own way.)
      
      There are some limitations, which should not be too hard to live with.  For
      atomic/blocking chains, registration and unregistration must always be done in
      a process context since the chain is protected by a mutex/rwsem.  Also, a
      callout routine for a non-raw chain must not try to register or unregister
      entries on its own chain.  (This did happen in a couple of places and the code
      had to be changed to avoid it.)
      
      Since atomic chains may be called from within an NMI handler, they cannot use
      spinlocks for synchronization.  Instead we use RCU.  The overhead falls almost
      entirely in the unregister routine, which is okay since unregistration is much
      less frequent that calling a chain.
      
      Here is the list of chains that we adjusted and their classifications.  None
      of them use the raw API, so for the moment it is only a placeholder.
      
        ATOMIC CHAINS
        -------------
      arch/i386/kernel/traps.c:		i386die_chain
      arch/ia64/kernel/traps.c:		ia64die_chain
      arch/powerpc/kernel/traps.c:		powerpc_die_chain
      arch/sparc64/kernel/traps.c:		sparc64die_chain
      arch/x86_64/kernel/traps.c:		die_chain
      drivers/char/ipmi/ipmi_si_intf.c:	xaction_notifier_list
      kernel/panic.c:				panic_notifier_list
      kernel/profile.c:			task_free_notifier
      net/bluetooth/hci_core.c:		hci_notifier
      net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_chain
      net/ipv4/netfilter/ip_conntrack_core.c:	ip_conntrack_expect_chain
      net/ipv6/addrconf.c:			inet6addr_chain
      net/netfilter/nf_conntrack_core.c:	nf_conntrack_chain
      net/netfilter/nf_conntrack_core.c:	nf_conntrack_expect_chain
      net/netlink/af_netlink.c:		netlink_chain
      
        BLOCKING CHAINS
        ---------------
      arch/powerpc/platforms/pseries/reconfig.c:	pSeries_reconfig_chain
      arch/s390/kernel/process.c:		idle_chain
      arch/x86_64/kernel/process.c		idle_notifier
      drivers/base/memory.c:			memory_chain
      drivers/cpufreq/cpufreq.c		cpufreq_policy_notifier_list
      drivers/cpufreq/cpufreq.c		cpufreq_transition_notifier_list
      drivers/macintosh/adb.c:		adb_client_list
      drivers/macintosh/via-pmu.c		sleep_notifier_list
      drivers/macintosh/via-pmu68k.c		sleep_notifier_list
      drivers/macintosh/windfarm_core.c	wf_client_list
      drivers/usb/core/notify.c		usb_notifier_list
      drivers/video/fbmem.c			fb_notifier_list
      kernel/cpu.c				cpu_chain
      kernel/module.c				module_notify_list
      kernel/profile.c			munmap_notifier
      kernel/profile.c			task_exit_notifier
      kernel/sys.c				reboot_notifier_list
      net/core/dev.c				netdev_chain
      net/decnet/dn_dev.c:			dnaddr_chain
      net/ipv4/devinet.c:			inetaddr_chain
      
      It's possible that some of these classifications are wrong.  If they are,
      please let us know or submit a patch to fix them.  Note that any chain that
      gets called very frequently should be atomic, because the rwsem read-locking
      used for blocking chains is very likely to incur cache misses on SMP systems.
      (However, if the chain's callout routines may sleep then the chain cannot be
      atomic.)
      
      The patch set was written by Alan Stern and Chandra Seetharaman, incorporating
      material written by Keith Owens and suggestions from Paul McKenney and Andrew
      Morton.
      
      [jes@sgi.com: restructure the notifier chain initialization macros]
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NChandra Seetharaman <sekharan@us.ibm.com>
      Signed-off-by: NJes Sorensen <jes@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e041c683
  23. 09 1月, 2006 1 次提交
    • O
      [PATCH] Fix compilation with CONFIG_MEMORY_HOTPLUG=y and gcc41. · b792de39
      Olaf Hering 提交于
      Fix compilation with CONFIG_MEMORY_HOTPLUG=y and gcc41.
      Also remove unneeded declations, add a public function.
      
      drivers/base/memory.c:53: error: static declaration of 'register_memory_notifier' follows non-static declaration
      include/linux/memory.h:85: error: previous declaration of 'register_memory_notifier' was here
      drivers/base/memory.c:58: error: static declaration of 'unregister_memory_notifier' follows non-static declaration
      include/linux/memory.h:86: error: previous declaration of 'unregister_memory_notifier' was here
      drivers/base/memory.c:68: error: static declaration of 'register_memory' follows non-static declaration
      include/linux/memory.h:73: error: previous declaration of 'register_memory' was here
      Signed-off-by: NOlaf Hering <olh@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b792de39
  24. 29 11月, 2005 1 次提交
  25. 07 11月, 2005 1 次提交
  26. 30 10月, 2005 1 次提交