1. 29 Apr, 2008 15 commits
    • Arjan van de Ven's avatar
      make /dev/kmem a config option · b781ecb6
      Arjan van de Ven authored
      Make /dev/kmem a config option; /dev/kmem is VERY rarely used, and when
      used, it's generally for no good (rootkits tend to be the most common
      users).  With this config option, users have the choice to disable
      /dev/kmem, saving some size as well.
      
      A patch to disable /dev/kmem has been in the Fedora and RHEL kernels for
      4+ years now without any known problems or legit users of /dev/kmem.
      
      [akpm@linux-foundation.org: make CONFIG_DEVKMEM default to y]
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b781ecb6
    • Harvey Harrison's avatar
      power: replace remaining __FUNCTION__ occurrences · 0cddc0a9
      Harvey Harrison authored
      __FUNCTION__ is gcc-specific, use __func__
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0cddc0a9
    • Nishanth Aravamudan's avatar
      page allocator: explicitly retry hugepage allocations · 551883ae
      Nishanth Aravamudan authored
      Add __GFP_REPEAT to hugepage allocations.  Do so to not necessitate userspace
      putting pressure on the VM by repeated echo's into /proc/sys/vm/nr_hugepages
      to grow the pool.  With the previous patch to allow for large-order
      __GFP_REPEAT attempts to loop for a bit (as opposed to indefinitely), this
      increases the likelihood of getting hugepages when the system experiences (or
      recently experienced) load.
      
      Mel tested the patchset on an x86_32 laptop.  With the patches, it was easier
      to use the proc interface to grow the hugepage pool.  The following is the
      output of a script that grows the pool as much as possible running on
      2.6.25-rc9.
      
      Allocating hugepages test
      -------------------------
      Disabling OOM Killer for current test process
      Starting page count: 0
      Attempt 1: 57 pages Progress made with 57 pages
      Attempt 2: 73 pages Progress made with 16 pages
      Attempt 3: 74 pages Progress made with 1 pages
      Attempt 4: 75 pages Progress made with 1 pages
      Attempt 5: 77 pages Progress made with 2 pages
      
      77 pages was the most it allocated but it took 5 attempts from userspace
      to get it. With the 3 patches in this series applied,
      
      Allocating hugepages test
      -------------------------
      Disabling OOM Killer for current test process
      Starting page count: 0
      Attempt 1: 75 pages Progress made with 75 pages
      Attempt 2: 76 pages Progress made with 1 pages
      Attempt 3: 79 pages Progress made with 3 pages
      
      And 79 pages was the most it got. Your patches were able to allocate the
      bulk of possible pages on the first attempt.
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Tested-by: default avatarMel Gorman <mel@csn.ul.ie>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Christoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      551883ae
    • Nishanth Aravamudan's avatar
      page allocator: smarter retry of costly-order allocations · a41f24ea
      Nishanth Aravamudan authored
      Because of page order checks in __alloc_pages(), hugepage (and similarly
      large order) allocations will not retry unless explicitly marked
      __GFP_REPEAT. However, the current retry logic is nearly an infinite
      loop (or until reclaim does no progress whatsoever). For these costly
      allocations, that seems like overkill and could potentially never
      terminate. Mel observed that allowing current __GFP_REPEAT semantics for
      hugepage allocations essentially killed the system. I believe this is
      because we may continue to reclaim small orders of pages all over, but
      never have enough to satisfy the hugepage allocation request. This is
      clearly only a problem for large order allocations, of which hugepages
      are the most obvious (to me).
      
      Modify try_to_free_pages() to indicate how many pages were reclaimed.
      Use that information in __alloc_pages() to eventually fail a large
      __GFP_REPEAT allocation when we've reclaimed an order of pages equal to
      or greater than the allocation's order. This relies on lumpy reclaim
      functioning as advertised. Due to fragmentation, lumpy reclaim may not
      be able to free up the order needed in one invocation, so multiple
      iterations may be requred. In other words, the more fragmented memory
      is, the more retry attempts __GFP_REPEAT will make (particularly for
      higher order allocations).
      
      This changes the semantics of __GFP_REPEAT subtly, but *only* for
      allocations > PAGE_ALLOC_COSTLY_ORDER. With this patch, for those size
      allocations, we will try up to some point (at least 1<<order reclaimed
      pages), rather than forever (which is the case for allocations <=
      PAGE_ALLOC_COSTLY_ORDER).
      
      This change improves the /proc/sys/vm/nr_hugepages interface with a
      follow-on patch that makes pool allocations use __GFP_REPEAT. Rather
      than administrators repeatedly echo'ing a particular value into the
      sysctl, and forcing reclaim into action manually, this change allows for
      the sysctl to attempt a reasonable effort itself. Similarly, dynamic
      pool growth should be more successful under load, as lumpy reclaim can
      try to free up pages, rather than failing right away.
      
      Choosing to reclaim only up to the order of the requested allocation
      strikes a balance between not failing hugepage allocations and returning
      to the caller when it's unlikely to every succeed. Because of lumpy
      reclaim, if we have freed the order requested, hopefully it has been in
      big chunks and those chunks will allow our allocation to succeed. If
      that isn't the case after freeing up the current order, I don't think it
      is likely to succeed in the future, although it is possible given a
      particular fragmentation pattern.
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Tested-by: default avatarMel Gorman <mel@csn.ul.ie>
      Cc: Dave Hansen <haveblue@us.ibm.com>
      Cc: Christoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a41f24ea
    • Nishanth Aravamudan's avatar
      mm: fix misleading __GFP_REPEAT related comments · ab857d09
      Nishanth Aravamudan authored
      The definition and use of __GFP_REPEAT, __GFP_NOFAIL and __GFP_NORETRY in the
      core VM have somewhat differing comments as to their actual semantics.
      Annoyingly, the flags definition has inline and header comments, which might
      be interpreted as not being equivalent.  Just add references to the header
      comments in the inline ones so they don't go out of sync in the future.  In
      their use in __alloc_pages() clarify that the current implementation treats
      low-order allocations and __GFP_REPEAT allocations as distinct cases.
      
      To clarify, the flags' semantics are:
      
      __GFP_NORETRY means try no harder than one run through __alloc_pages
      
      __GFP_REPEAT means __GFP_NOFAIL
      
      __GFP_NOFAIL means repeat forever
      
      order <= PAGE_ALLOC_COSTLY_ORDER means __GFP_NOFAIL
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Acked-by: default avatarMel Gorman <mel@csn.ul.ie>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ab857d09
    • KAMEZAWA Hiroyuki's avatar
      mm: fix usemap initialization · 86051ca5
      KAMEZAWA Hiroyuki authored
      usemap must be initialized only when pfn is within zone.  If not, it corrupts
      memory.
      
      And this patch also reduces the number of calls to set_pageblock_migratetype()
      from
      	(pfn & (pageblock_nr_pages -1)
      to
      	!(pfn & (pageblock_nr_pages-1)
      it should be called once per pageblock.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: default avatarMel Gorman <mel@csn.ul.ie>
      Cc: Hugh Dickins <hugh@veritas.com>
      Cc: Shi Weihua <shiwh@cn.fujitsu.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Pavel Emelyanov <xemul@openvz.org>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      86051ca5
    • Harvey Harrison's avatar
    • Harvey Harrison's avatar
      media: fix integer as NULL pointer warnings · a6a3a17b
      Harvey Harrison authored
      drivers/media/video/v4l2-common.c:719:16: warning: Using plain integer as NULL pointer
      drivers/media/video/au0828/au0828-dvb.c:122:19: warning: Using plain integer as NULL pointer
      drivers/media/video/ivtv/ivtv-yuv.c:1101:22: warning: Using plain integer as NULL pointer
      drivers/media/video/ivtv/ivtv-yuv.c:1102:23: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-audio.c:78:39: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-video-v4l.c:84:39: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-v4l2.c:1264:9: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-context.c:197:28: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c:126:39: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-dvb.c:133:32: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-dvb.c:145:31: warning: Using plain integer as NULL pointer
      drivers/media/video/pvrusb2/pvrusb2-dvb.c:177:55: warning: Using plain integer as NULL pointer
      drivers/media/video/videobuf-core.c:100:9: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a6a3a17b
    • Harvey Harrison's avatar
      scsi: fix integer as NULL pointer warnings · 172c122d
      Harvey Harrison authored
      drivers/scsi/aic7xxx/aic7770_osm.c:53:58: warning: Using plain integer as NULL pointer
      drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:355:47: warning: Using plain integer as NULL pointer
      drivers/scsi/aic7xxx/aic7xxx_osm_pci.c:372:55: warning: Using plain integer as NULL pointer
      drivers/scsi/aha152x.c:997:28: warning: Using plain integer as NULL pointer
      drivers/scsi/aha152x.c:1003:28: warning: Using plain integer as NULL pointer
      drivers/scsi/aha152x.c:1165:46: warning: Using plain integer as NULL pointer
      drivers/scsi/fdomain.c:1446:40: warning: Using plain integer as NULL pointer
      drivers/scsi/sym53c8xx_2/sym_hipd.c:1650:51: warning: Using plain integer as NULL pointer
      drivers/scsi/sym53c8xx_2/sym_hipd.c:3171:42: warning: Using plain integer as NULL pointer
      drivers/scsi/sym53c8xx_2/sym_hipd.c:5732:52: warning: Using plain integer as NULL pointer
      drivers/scsi/ncr53c8xx.c:8189:31: warning: Using plain integer as NULL pointer
      drivers/scsi/ncr53c8xx.c:8225:34: warning: Using plain integer as NULL pointer
      drivers/scsi/dpt_i2o.c:156:32: warning: Using plain integer as NULL pointer
      drivers/scsi/ultrastor.c:954:42: warning: Using plain integer as NULL pointer
      drivers/scsi/ultrastor.c:1104:18: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      172c122d
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6 · 8ab68ab4
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: (35 commits)
        siimage: coding style cleanup (take 2)
        ide-cd: clean up cdrom_analyze_sense_data()
        ide-cd: fix test unsigned var < 0
        ide: add TSSTcorp CDDVDW SH-S202H to ivb_list[]
        piix: add Asus Eee 701 controller to short cable list
        ARM: always select HAVE_IDE
        remove the broken ETRAX_IDE driver
        ide: remove ->dma_prdtable field from ide_hwif_t
        ide: remove ->dma_vendor{1,3} fields from ide_hwif_t
        scc_pata: add ->dma_host_set and ->dma_start methods
        ide: skip "VLB sync" if host uses MMIO
        ide: add ide_pad_transfer() helper
        ide: remove ->INW and ->OUTW methods
        ide: use IDE I/O helpers directly in ide_tf_{load,read}()
        ns87415: add ->tf_read method
        scc_pata: add ->tf_{load,read} methods
        ide-h8300: add ->tf_{load,read} methods
        ide-cris: add ->tf_{load,read} methods
        ide: add ->tf_load and ->tf_read methods
        ide: move ide_tf_{load,read} to ide-iops.c
        ...
      8ab68ab4
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild · f05c463b
      Linus Torvalds authored
      * git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild:
        kconfig: add named choice group
        kconfig: fix choice dependency check
        kconifg: 'select' considered less evil
        dontdiff: ignore timeconst.h
        dontdiff: add modules.order
        kbuild: fix unportability in gen_initramfs_list.sh
        kbuild: fix help output to show correct arch
        kbuild: show defconfig subdirs in make help
        kconfig: reversed borderlines in inputbox
      f05c463b
    • Harvey Harrison's avatar
      drivers: atm, char fix integer as NULL pointer warnings · 8da56309
      Harvey Harrison authored
      drivers/atm/nicstar.c:418:25: warning: Using plain integer as NULL pointer
      drivers/char/drm/r128_cce.c:820:25: warning: Using plain integer as NULL pointer
      drivers/char/tty_io.c:1183:10: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8da56309
    • Harvey Harrison's avatar
      mm: fix integer as NULL pointer warnings · 7b8ee84d
      Harvey Harrison authored
      mm/hugetlb.c:207:11: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7b8ee84d
    • Harvey Harrison's avatar
      kernel: fix integer as NULL pointer warnings · b331d259
      Harvey Harrison authored
      kernel/cpuset.c:1268:52: warning: Using plain integer as NULL pointer
      kernel/pid_namespace.c:95:24: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Reviewed-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b331d259
    • Harvey Harrison's avatar
      init: fix integer as NULL pointer warnings · d613c3e2
      Harvey Harrison authored
      init/do_mounts_rd.c:215:13: warning: Using plain integer as NULL pointer
      init/do_mounts_md.c:136:45: warning: Using plain integer as NULL pointer
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d613c3e2
  2. 28 Apr, 2008 25 commits