1. 01 May, 2005 13 commits
    • Manfred Spraul's avatar
      [PATCH] add kmalloc_node, inline cleanup · 97e2bde4
      Manfred Spraul authored
      The patch makes the following function calls available to allocate memory
      on a specific node without changing the basic operation of the slab
      allocator:
      
       kmem_cache_alloc_node(kmem_cache_t *cachep, unsigned int flags, int node);
       kmalloc_node(size_t size, unsigned int flags, int node);
      
      in a similar way to the existing node-blind functions:
      
       kmem_cache_alloc(kmem_cache_t *cachep, unsigned int flags);
       kmalloc(size, flags);
      
      kmem_cache_alloc_node was changed to pass flags and the node information
      through the existing layers of the slab allocator (which lead to some minor
      rearrangements).  The functions at the lowest layer (kmem_getpages,
      cache_grow) are already node aware.  Also __alloc_percpu can call
      kmalloc_node now.
      
      Performance measurements (using the pageset localization patch) yields:
      
      w/o patches:
      Tasks    jobs/min  jti  jobs/min/task      real       cpu
          1      484.27  100       484.2736     12.02      1.97   Wed Mar 30 20:50:43 2005
        100    25170.83   91       251.7083     23.12    150.10   Wed Mar 30 20:51:06 2005
        200    34601.66   84       173.0083     33.64    294.14   Wed Mar 30 20:51:40 2005
        300    37154.47   86       123.8482     46.99    436.56   Wed Mar 30 20:52:28 2005
        400    39839.82   80        99.5995     58.43    580.46   Wed Mar 30 20:53:27 2005
        500    40036.32   79        80.0726     72.68    728.60   Wed Mar 30 20:54:40 2005
        600    44074.21   79        73.4570     79.23    872.10   Wed Mar 30 20:55:59 2005
        700    44016.60   78        62.8809     92.56   1015.84   Wed Mar 30 20:57:32 2005
        800    40411.05   80        50.5138    115.22   1161.13   Wed Mar 30 20:59:28 2005
        900    42298.56   79        46.9984    123.83   1303.42   Wed Mar 30 21:01:33 2005
       1000    40955.05   80        40.9551    142.11   1441.92   Wed Mar 30 21:03:55 2005
      
      with pageset localization and slab API patches:
      Tasks    jobs/min  jti  jobs/min/task      real       cpu
          1      484.19  100       484.1930     12.02      1.98   Wed Mar 30 21:10:18 2005
        100    27428.25   92       274.2825     21.22    149.79   Wed Mar 30 21:10:40 2005
        200    37228.94   86       186.1447     31.27    293.49   Wed Mar 30 21:11:12 2005
        300    41725.42   85       139.0847     41.84    434.10   Wed Mar 30 21:11:54 2005
        400    43032.22   82       107.5805     54.10    582.06   Wed Mar 30 21:12:48 2005
        500    42211.23   83        84.4225     68.94    722.61   Wed Mar 30 21:13:58 2005
        600    40084.49   82        66.8075     87.12    873.11   Wed Mar 30 21:15:25 2005
        700    44169.30   79        63.0990     92.24   1008.77   Wed Mar 30 21:16:58 2005
        800    43097.94   79        53.8724    108.03   1155.88   Wed Mar 30 21:18:47 2005
        900    41846.75   79        46.4964    125.17   1303.38   Wed Mar 30 21:20:52 2005
       1000    40247.85   79        40.2478    144.60   1442.21   Wed Mar 30 21:23:17 2005
      Signed-off-by: default avatarChristoph Lameter <christoph@lameter.com>
      Signed-off-by: default avatarManfred Spraul <manfred@colorfullife.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      97e2bde4
    • William Lee Irwin III's avatar
      [PATCH] sync_page() smp_mb() comment · dd1d5afc
      William Lee Irwin III authored
      The smp_mb() is becaus sync_page() doesn't have PG_locked while it accesses
      page_mapping(page).  The comments in the patch (the entire patch is the
      addition of this comment) try to explain further how and why smp_mb() is
      used.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      dd1d5afc
    • Chris Wright's avatar
      [PATCH] RLIMIT_MEMLOCK checking fix · 93ea1d0a
      Chris Wright authored
      Always use page counts when doing RLIMIT_MEMLOCK checking to avoid possible
      overflow.
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      93ea1d0a
    • KAMEZAWA Hiroyuki's avatar
      [PATCH] count bounce buffer pages in vmstat · edfbe2b0
      KAMEZAWA Hiroyuki authored
      This is a patch for counting the number of pages for bounce buffers.  It's
      shown in /proc/vmstat.
      
      Currently, the number of bounce pages are not counted anywhere.  So, if
      there are many bounce pages, it seems that there are leaked pages.  And
      it's difficult for a user to imagine the usage of bounce pages.  So, it's
      meaningful to show # of bouce pages.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      edfbe2b0
    • Nikita Danilov's avatar
      [PATCH] doc: Locking update · 2054606a
      Nikita Danilov authored
      Make the Locking document truer.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2054606a
    • Nick Piggin's avatar
      [PATCH] mm: use __GFP_NOMEMALLOC · bd53b714
      Nick Piggin authored
      Use the new __GFP_NOMEMALLOC to simplify the previous handling of
      PF_MEMALLOC.
      Signed-off-by: default avatarNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      bd53b714
    • Nick Piggin's avatar
      [PATCH] mempool: simplify alloc · 20a77776
      Nick Piggin authored
      Mempool is pretty clever.  Looks too clever for its own good :) It
      shouldn't really know so much about page reclaim internals.
      
      - don't guess about what effective page reclaim might involve.
      
      - don't randomly flush out all dirty data if some unlikely thing
        happens (alloc returns NULL). page reclaim can (sort of :P) handle
        it.
      
      I think the main motivation is trying to avoid pool->lock at all costs.
      However the first allocation is attempted with __GFP_WAIT cleared, so it
      will be 'can_try_harder' if it hits the page allocator.  So if allocation
      still fails, then we can probably afford to hit the pool->lock - and what's
      the alternative?  Try page reclaim and hit zone->lru_lock?
      
      A nice upshot is that we don't need to do any fancy memory barriers or do
      (intentionally) racy access to pool-> fields outside the lock.
      Signed-off-by: default avatarNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      20a77776
    • Nick Piggin's avatar
      [PATCH] mempool: NOMEMALLOC and NORETRY · b84a35be
      Nick Piggin authored
      Mempools have 2 problems.
      
      The first is that mempool_alloc can possibly get stuck in __alloc_pages
      when they should opt to fail, and take an element from their reserved pool.
      
      The second is that it will happily eat emergency PF_MEMALLOC reserves
      instead of going to their reserved pools.
      
      Fix the first by passing __GFP_NORETRY in the allocation calls in
      mempool_alloc.  Fix the second by introducing a __GFP_MEMPOOL flag which
      directs the page allocator not to allocate from the reserve pool.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b84a35be
    • Nick Piggin's avatar
      [PATCH] mm: pcp use non powers of 2 for batch size · 8e30f272
      Nick Piggin authored
      Jack Steiner reported this to have fixed his problem (bad colouring):
      "The patches fix both problems that I found - bad
       coloring & excessive pages in pagesets."
      
      In most workloads this is not likely to be such a pronounced problem,
      however it should help corner cases.  And avoiding powers of 2 in these
      types of memory operations is always a good idea.
      Signed-off-by: default avatarNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8e30f272
    • Nikita Danilov's avatar
      [PATCH] mm: rmap.c cleanup · 81b4082d
      Nikita Danilov authored
      mm/rmap.c:page_referenced_one() and mm/rmap.c:try_to_unmap_one() contain
      identical code that
      
       - takes mm->page_table_lock;
      
       - drills through page tables;
      
       - checks that correct pte is reached.
      
      Coalesce this into page_check_address()
      Signed-off-by: default avatarNikita Danilov <nikita@clusterfs.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      81b4082d
    • akpm@osdl.org's avatar
      [PATCH] RLIMIT_AS checking fix · 119f657c
      akpm@osdl.org authored
      Address bug #4508: there's potential for wraparound in the various places
      where we perform RLIMIT_AS checking.
      
      (I'm a bit worried about acct_stack_growth().  Are we sure that vma->vm_mm is
      always equal to current->mm?  If not, then we're comparing some other
      process's total_vm with the calling process's rlimits).
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      119f657c
    • akpm@osdl.org's avatar
      [PATCH] generic_file_buffered_write fixes · f021e921
      akpm@osdl.org authored
      Anton Altaparmakov <aia21@cam.ac.uk> points out:
      
      - It calls fault_in_pages_readable() which is completely bogus if @nr_segs >
        1.  It needs to be replaced by a to be written
        "fault_in_pages_readable_iovec()".
      
      - It increments @buf even in the iovec case thus @buf can point to random
        memory really quickly (in the iovec case) and then it calls
        fault_in_pages_readable() on this random memory.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f021e921
    • akpm@osdl.org's avatar
      [PATCH] ultrastor build fix · 69aa3f71
      akpm@osdl.org authored
      Fix a typo.
      
      James Bottomley <James.Bottomley@steeleye.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      69aa3f71
  2. 30 Apr, 2005 13 commits
  3. 29 Apr, 2005 14 commits
    • Linus Torvalds's avatar
    • Linus Torvalds's avatar
      dd96a8e0
    • Sascha Hauer's avatar
      [PATCH] ARM: 2654/1: i.MX UART initialization sets and honors UFCR value · 587897f5
      Sascha Hauer authored
      Patch from Sascha Hauer
      
      This patch adds UCFR_RFDIV setting into i.MX serial driver.
      This is required, if loader does not fully agree with Linux kernel
      about UART setup manner. Linux only blindly expected some values until
      now. This should enable to use even serial ports not recognized by
      boot-loader as for example third UART found in the bluethoot module.
      Patch also enables to detect original setup baudrate in more cases.
      
      Signed-off-by: Pavel Pisa
      Signed-off-by: Sascha Hauer
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      587897f5
    • Lennert Buytenhek's avatar
      [PATCH] ARM: 2660/2: fix ixdp2800 boot and pci init · 53e173f6
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      The IXDP2800 is an evalution platform for the IXP2800 processor that
      has two IXP2800s connected to the same PCI bus.  This is problematic
      as both CPUs will try to configure the PCI bus as they boot linux.
      Contrary to on the other IXP2000 platforms, the boot loader on the
      IXDP2800 doesn't configure the PCI bus properly, so we do want the
      linux instance on one of the CPUs to do that.
      Making one of the CPUs ignore the PCI bus (and thus act like a pure
      PCI slave device) is not an option because there is a 82559 NIC on
      the PCI bus for each of the CPUs.
      The chosen solution is to have the master CPU configure the PCI bus
      while the slave is kept in a quiescent state, and then to have the
      slave CPU scan the PCI bus (without assigning resources) while the
      master is kept in a quiescent state.  After this ritual, the master
      deletes the slave NIC from its PCI device list, the slave deletes
      the master NIC from its device list, and (almost) all is well.
      There's still one little problem: each of the CPUs has a 1G SDRAM
      BAR, but the IXP2000 only has 512M of outbound PCI memory window.
      We solve this by hand-assigning the master and slave SDRAM BARs to
      a location outside each of the IXP's outbound PCI windows, and by
      having the rest of the BARs autoconfigured in the outbound PCI
      windows, in the range [e0000000..ffffffff], so that there is a 1:1
      pci:phys mapping between them.
      Even with this patch, a number of issues still remain -- just imagine
      what happens if one of the CPUs is rebooted, by watchdog or by hand,
      but the other one isn't.  But those issues are not easily fixable
      given the strange PCI layout of this board and the behavior of the
      boot loader shipped with the platform.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      53e173f6
    • George G. Davis's avatar
      [PATCH] ARM: 2656/1: Access permission bits are wrong for kernel XIP sections on ARMv6 · ca315159
      George G. Davis authored
      Patch from George G. Davis
      
      This patch is required for kernel XIP support on ARMv6 machines.  It ensures that the access permission bits for kernel XIP section descriptors are APX=1 and AP[1:0]=01, which is Kernel read-only/User no access permissions.  Prior to this change, kernel XIP section descriptor access permissions were set to Kernel no access/User no access on ARMv6 machines and the kernel would therefore hang upon entry to userspace when set_fs(USER_DS) was executed.
      
      Signed-off-by: Steve Longerbeam
      Signed-off-by: George G. Davis
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ca315159
    • Olav Kongas's avatar
      [PATCH] ARM: 2649/1: Fix 'sparse -Wbitwise' warnings from MMIO macros · 05f9869b
      Olav Kongas authored
      Patch from Olav Kongas
      
      On ARM, the outX() and writeX() families of macros take the
      result of cpu_to_leYY(), which is of restricted type __leYY,
      and feed it to __raw_writeX(), which expect an argument of
      unrestricted type. This results in 'sparse -Wbitwise'
      warnings about incorrect types in assignments. Analogous
      type mismatch warnings are issued for inX() and readX()
      counterparts. The below patch resolves these warnings by
      adding forced typecasts.
      
      Signed-off-by: Olav Kongas
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      05f9869b
    • Nicolas Pitre's avatar
      [PATCH] ARM: 2651/3: kernel helpers for NPTL support · 2d2669b6
      Nicolas Pitre authored
      Patch from Nicolas Pitre
      
      This patch entirely reworks the kernel assistance for NPTL on ARM.
      In particular this provides an efficient way to retrieve the TLS
      value and perform atomic operations without any instruction emulation
      nor special system call.  This even allows for pre ARMv6 binaries to
      be forward compatible with SMP systems without any penalty.
      The problematic and performance critical operations are performed
      through segment of kernel provided user code reachable from user space
      at a fixed address in kernel memory.  Those fixed entry points are
      within the vector page so we basically get it for free as no extra
      memory page is required and nothing else may be mapped at that
      location anyway.
      This is different from (but doesn't preclude) a full blown VDSO
      implementation, however a VDSO would prevent some assembly tricks with
      constants that allows for efficient branching to those code segments.
      And since those code segments only use a few cycles before returning to
      user code, the overhead of a VDSO far call would add a significant
      overhead to such minimalistic operations.
      The ARM_NR_set_tls syscall also changed number.  This is done for two
      reasons:
      1) this patch changes the way the TLS value was previously meant to be
         retrieved, therefore we ensure whatever library using the old way
         gets fixed (they only exist in private tree at the moment since the
         NPTL work is still progressing).
      2) the previous number was allocated in a range causing an undefined
         instruction trap on kernels not supporting that syscall and it was
         determined that allocating it in a range returning -ENOSYS would be
         much nicer for libraries trying to determine if the feature is
         present or not.
      
      Signed-off-by: Nicolas Pitre
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      2d2669b6
    • George G. Davis's avatar
      [PATCH] ARM: 2655/1: ARM1136 SWP instruction abort handler fix · 3a1e5015
      George G. Davis authored
      Patch from George G. Davis
      
      As noted in http://www.arm.com/linux/patch-2.6.9-arm1.gz, the "Faulty SWP instruction on 1136 doesn't set bit 11 in DFSR." So the v6_early_abort handler does not report the correct rd/wr direction for the SWP instruction which may result in SEGVS or hangs. In order to work around this problem, this patch merely updates the fix contained in the ARM Ltd. patch to use the macroised abort handler fixups.
      
      Signed-off-by: George G. Davis
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      3a1e5015
    • Lennert Buytenhek's avatar
      [PATCH] ARM: 2659/1: do not assign PCI I/O address zero on IXP2000 · 458a83fa
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      Assigning the address zero to a PCI device BAR causes some part of the
      PCI subsystem to believe that resource allocation for that BAR failed
      due to resource conflicts, which will make attempts to enable the
      device fail.  Work around this by assigning I/O addresses starting
      from 00010000.
      While we're at it, make the PCI I/O resource end at 0001ffff, since we
      only have 64k of outbound I/O window on the IXP2000, and we don't do
      bank switching.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      458a83fa
    • Lennert Buytenhek's avatar
      [PATCH] ARM: 2658/1: start ixp2000 pci memory resource at 0xe0000000 · ae36bf58
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      On the IXDP2800, the bootloader does an awful job of configuring
      the PCI bus, so we make linux reconfigure everything.  Having a 1:1
      pci:phys address mapping generally simplifies everything, so try to
      allocate PCI addresses from the [e0000000..ffffffff] range, which is
      the physical address range of the outbound PCI window on the IXP2000.
      This does not affect any of the other IXP2000 platforms since they
      all use their bootloader's PCI resource assignment.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ae36bf58
    • Lennert Buytenhek's avatar
      [PATCH] ARM: 2657/1: export ixp2000_pci_config_addr · 8443b165
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      Export ixp2000_pci_config_addr, to be used by the IXDP2800 platform
      setup code to coordinate booting the master and slave NPU.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Deepak Saxena
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      8443b165
    • Linus Torvalds's avatar
      x86: make traps on 'iret' be debuggable in user space · a879cbbb
      Linus Torvalds authored
      This makes a trap on the 'iret' that returns us to user space
      cause a nice clean SIGSEGV, instead of just a hard (and silent)
      exit.
      
      That way a debugger can actually try to see what happened, and
      we also properly notify everybody who might be interested about
      us being gone.
      
      This loses the error code, but tells the debugger what happened
      with ILL_BADSTK in the siginfo.
      a879cbbb
    • Linus Torvalds's avatar
      Remove bogus BUG() in kernel/exit.c · c06fec50
      Linus Torvalds authored
      It's old sanity checking that may have been useful for debugging, but
      is just bogus these days.
      
      Noticed by Mattia Belletti.
      c06fec50
    • Benjamin Herrenschmidt's avatar
      [PATCH] Add suspend method to cpufreq core · 42d4dc3f
      Benjamin Herrenschmidt authored
      In order to properly fix some issues with cpufreq vs. sleep on
      PowerBooks, I had to add a suspend callback to the pmac_cpufreq driver.
      I must force a switch to full speed before sleep and I switch back to
      previous speed on resume.
      
      I also added a driver flag to disable the warnings in suspend/resume
      since it is expected in this case to have different speed (and I want it
      to fixup the jiffies properly).
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      42d4dc3f