An error occurred fetching the project authors.
  1. 08 Jan, 2005 1 commit
  2. 07 Jan, 2005 1 commit
    • David Mosberger's avatar
      [IA64] add hpzx1_swiotlb machine-vector · b733ce21
      David Mosberger authored
      I was in need of a 3.3V/dual-voltage-capable PCI sound-card and, as
      luck would have it, the only card of that sort in the local computer
      store was one that _still_ has a DMA engine that cannot even DMA to
      all 32 bits (it's limited to 28 bits).  Hard to believe, but true (the
      card in question is a "SoundBlaster Live! 24-bit" with a CA0106 chip;
      stay away from that one if you can...).
      
      Anyhow, since I don't like it when PCI cards don't work in my machine,
      I created the attached patch which adds a new machine-vector to enable
      support of such broken cards.
      
      With the patch applied, you can either configure the kernel for
      "HP-zx1/sx1000+swiotlb" or configure for "generic" and boot with
      option "machvec=hpzx1_swiotlb" to enable support for broken PCI
      devices.
      
      The patch works as follows: the new machvec implements a I/O MMU which
      will use the hardware I/O MMU whenever possible but fall back on the
      software I/O TLB when encountering a device that can't be supported by
      the hardware I/O MMU.  Fortunately, we don't have to mess with
      MAX_DMA_ADDRESS or create a new zone: the software I/O TLB allocates
      its memory as low as possible and early in the boot-process, so on any
      machine with low memory, we're pretty much guaranteed that we'll get a
      reasonable amount of low memory, which is all we need to properly support
      broken PCI cards.
      
      Note that I made a small change to swiotlb.c: I added a
      swiotlb_init_with_default_size() function to let the new I/O MMU
      initialize the software I/O TLB with less than 64MB (which is way too
      much for the limited uses we'll see for the broken PCI devices; for
      example, the CA0106 chip allocates only coherent buffers of about
      128KB).
      
      The patch has been tested on a zx1 machine in the generic, hpzx1, and
      hpzx1_swiotlb configuration.
      
      Thanks to Alex Williamson for the suggestion of doing this via a
      completely separate machvec.
      Signed-off-by: default avatarDavid Mosberger-Tang <davidm@hpl.hp.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      b733ce21
  3. 04 Jan, 2005 2 commits
  4. 03 Jan, 2005 1 commit
    • Brent Casavant's avatar
      [PATCH] alloc_large_system_hash: NUMA interleaving · dcee73c4
      Brent Casavant authored
      NUMA systems running current Linux kernels suffer from substantial inequities
      in the amount of memory allocated from each NUMA node during boot.  In
      particular, several large hashes are allocated using alloc_bootmem, and as
      such are allocated contiguously from a single node each.
      
      This becomes a problem for certain workloads that are relatively common on
      big-iron HPC NUMA systems.  In particular, a number of MPI and OpenMP
      applications which require nearly all available processors in the system and
      nearly all the memory on each node run into difficulties.  Due to the uneven
      memory distribution onto a few nodes, any thread on those nodes will require a
      portion of its memory be allocated from remote nodes.  Any access to those
      memory locations will be slower than local accesses, and thereby slows down
      the effective computation rate for the affected CPUs/threads.  This problem is
      further amplified if the application is tightly synchronized between threads
      (as is often the case), as they entire job can run only at the speed of the
      slowest thread.
      
      Additionally since these hashes are usually accessed by all CPUS in the
      system, the NUMA network link on the node which hosts the hash experiences
      disproportionate traffic levels, thereby reducing the memory bandwidth
      available to that node's CPUs, and further penalizing performance of the
      threads executed thereupon.
      
      As such, it is desired to find a way to distribute these large hash
      allocations more evenly across NUMA nodes.  Fortunately current kernels do
      perform allocation interleaving for vmalloc() during boot, which provides a
      stepping stone to a solution.
      
      This series of patches enables (but does not require) the kernel to allocate
      several boot time hashes using vmalloc rather than alloc_bootmem, thereby
      causing the hashes to be interleaved amongst NUMA nodes.  In particular the
      dentry cache, inode cache, TCP ehash, and TCP bhash have been changed to be
      allocated in this manner.  Due to the limited vmalloc space on architectures
      such as i386, this behavior is turned on by default only for IA64 NUMA systems
      (though there is no reason other interested architectures could not enable it
      if desired).  Non-IA64 and non-NUMA systems continue to use the existing
      alloc_bootmem() allocation mechanism.  A boot line parameter "hashdist" can be
      set to override the default behavior.
      
      The following two sets of example output show the uneven distribution just
      after boot, using init=/bin/sh to eliminate as much non-kernel allocation as
      possible.
      
      Without the boot hash distribution patches:
      
       Nid  MemTotal   MemFree   MemUsed      (in kB)
         0   3870656   3697696    172960
         1   3882992   3866656     16336
         2   3883008   3866784     16224
         3   3882992   3866464     16528
         4   3883008   3866592     16416
         5   3883008   3866720     16288
         6   3882992   3342176    540816
         7   3883008   3865440     17568
         8   3882992   3866560     16432
         9   3883008   3866400     16608
        10   3882992   3866592     16400
        11   3883008   3866400     16608
        12   3882992   3866400     16592
        13   3883008   3866432     16576
        14   3883008   3866528     16480
        15   3864768   3848256     16512
       ToT  62097440  61152096    945344
      
      Notice that nodes 0 and 6 have a substantially larger memory utilization
      than all other nodes.
      
      With the boot hash distribution patch:
      
       Nid  MemTotal   MemFree   MemUsed      (in kB)
         0   3870656   3789792     80864
         1   3882992   3843776     39216
         2   3883008   3843808     39200
         3   3882992   3843904     39088
         4   3883008   3827488     55520
         5   3883008   3843712     39296
         6   3882992   3843936     39056
         7   3883008   3844096     38912
         8   3882992   3843712     39280
         9   3883008   3844000     39008
        10   3882992   3843872     39120
        11   3883008   3843872     39136
        12   3882992   3843808     39184
        13   3883008   3843936     39072
        14   3883008   3843712     39296
        15   3864768   3825760     39008
       ToT  62097440  61413184    684256
      
      While not perfectly even, we can see that there is a substantial improvement
      in the spread of memory allocated by the kernel during boot.  The remaining
      uneveness may be due in part to further boot time allocations that could be
      addressed in a similar manner, but some difference is due to the somewhat
      special nature of node 0 during boot.  However the uneveness has fallen to a
      much more acceptable level (at least to a level that SGI isn't concerned
      about).
      
      The astute reader will also notice that in this example, with this patch
      approximately 256 MB less memory was allocated during boot.  This is due to
      the size limits of a single vmalloc.  More specifically, this is because the
      automatically computed size of the TCP ehash exceeds the maximum size which a
      single vmalloc can accomodate.  However this is of little practical concern as
      the vmalloc size limit simply reduces one ridiculously large allocation
      (512MB) to a slightly less ridiculously large allocation (256MB).  In practice
      machines with large memory configurations are using the thash_entries setting
      to limit the size of the TCP ehash _much_ lower than either of the
      automatically computed values.  Illustrative of the exceedingly large nature
      of the automatically computed size, SGI currently recommends that customers
      boot with thash_entries=2097152, which works out to a 32MB allocation.  In any
      case, setting hashdist=0 will allow for allocations in excess of vmalloc
      limits, if so desired.
      
      Other than the vmalloc limit, great care was taken to ensure that the size of
      TCP hash allocations was not altered by this patch.  Due to slightly different
      computation techniques between the existing TCP code and
      alloc_large_system_hash (which is now utilized), some of the magic constants
      in the TCP hash allocation code were changed.  On all sizes of system (128MB
      through 64GB) that I had access to, the patched code preserves the previous
      hash size, as long as the vmalloc limit (256MB on IA64) is not encountered.
      
      There was concern that changing the TCP-related hashes to use vmalloc space
      may adversely impact network performance.  To this end the netperf set of
      benchmarks was run.  Some individual tests seemed to benefit slightly, some
      seemed to be harmed slightly, but in all cases the average difference with and
      without these patches was well within the variabilty I would see from run to
      run.
      
      The following is the overall netperf averages (30 10 second runs each) against
      an older kernel with these same patches.  These tests were run over loopback
      as GigE results were so inconsistent run to run both with and without these
      patches that they provided no meaningful comparison that I could discern.  I
      used the same kernel (IA64 generic) for each run, simply varying the new
      "hashdist" boot parameter to turn on or off the new allocation behavior.  In
      all cases the thash_entries value was manually specified as discussed
      previously to eliminate any variability that might result from that size
      difference.
      
      HP ZX1, hashdist=0
      ==================
      TCP_RR = 19389
      TCP_MAERTS = 6561 
      TCP_STREAM = 6590 
      TCP_CC = 9483
      TCP_CRR = 8633 
      
      HP ZX1, hashdist=1
      ==================
      TCP_RR = 19411
      TCP_MAERTS = 6559 
      TCP_STREAM = 6584 
      TCP_CC = 9454
      TCP_CRR = 8626 
      
      SGI Altix, hashdist=0
      =====================
      TCP_RR = 16871
      TCP_MAERTS = 3925 
      TCP_STREAM = 4055 
      TCP_CC = 8438
      TCP_CRR = 7750 
      
      SGI Altix, hashdist=1
      =====================
      TCP_RR = 17040
      TCP_MAERTS = 3913 
      TCP_STREAM = 4044 
      TCP_CC = 8367
      TCP_CRR = 7538 
      
      I believe the TCP_CC and TCP_CRR are the tests most sensitive to this
      particular change.  But again, I want to emphasize that even the differences
      you see above are _well_ within the variability I saw from run to run of any
      given test.
      
      In addition, Jose Santos at IBM has run specSFS, which has been particularly
      sensitive to TLB issues, against these patches and saw no performance
      degredation (differences down in the noise).
      
      
      
      This patch:
      
      Modifies alloc_large_system_hash to enable the use of vmalloc to alleviate
      boottime allocation imbalances on NUMA systems.
      
      Due to limited vmalloc space on some architectures (i.e.  x86), the use of
      vmalloc is enabled by default only on NUMA IA64 kernels.  There should be
      no problem enabling this change for any other interested NUMA architecture.
      Signed-off-by: default avatarBrent Casavant <bcasavan@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      dcee73c4
  5. 13 Dec, 2004 2 commits
  6. 05 Dec, 2004 1 commit
  7. 01 Dec, 2004 1 commit
  8. 19 Nov, 2004 2 commits
  9. 18 Nov, 2004 1 commit
  10. 16 Nov, 2004 1 commit
  11. 14 Nov, 2004 1 commit
  12. 07 Nov, 2004 3 commits
    • James Nelson's avatar
      [PATCH] ramdisk: Correction to Documentation/kernel-parameters.txt · 44185861
      James Nelson authored
      Remove deleted module option in Documentation/kernel-parameters.txt
      Signed-off-by: default avatarJames Nelson <james4765@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      44185861
    • Pavel Fedin's avatar
      [PATCH] VIA8231 support for parallel port driver · 1eccda34
      Pavel Fedin authored
      This patch allows the kernel to configure port's mode without help of BIOS.
       It is needed on my machine because its firmware simply ignores the
      parallel port leaving in unidirectional SPP mode.
      
      Notes on usage:
      
      To configure the port you need to:
      
      - if parport_pc driver is compiled as a module: specify parport_pc
        init_mode=[spp|ps2|epp|ecp|ecpepp] in /etc/modules file (for Debian
        Linux).
      
      - if the driver is linked statically with the kernel: specify
        parport_init_mode=[spp|ps2|epp|ecp|ecpepp] in kernel's arguments.
      
      This patch is intended for use primarily on Pegasos machines but it will
      work on any computer with VIA8231 south bridge.  In this case it will
      override BIOS setting if you tell the driver to configure the port.  BIOS
      setting will be honored if you omit init_mode parameter.  Technical
      details:
      
      1.  On Pegasos standard port settings (set by OpenFirmware) are: IRQ=7,
          DMA=3, base address=0x3BC, mode is unidirectional SPP.
      
      2.  The patch changes only port mode, all other settings are preserved.
           So if you have a PC with VIA8231 and use driver to configure the port
          you'll still be able to change IRQ, DMA and base address in BIOS and
          these settings will be kept.
      
      3.  One exclusion: if you tell the driver to turn on EPP mode (specify
          epp or ecpepp value) and if default base address is 0x3BC (this is the
          case on Pegasos) the port will be moved to 0x378.  EPP port can't have
          0x3BC as the base.
      
      Known problems:
      
      1.  ECP+EPP mode is strange, it doesn't work even on several PC's i
          tested with Linux.  ECP mode is detected and EPP is not.  So if you get
          the same thing, it's not my fault.  I just have no time to deal with
          it, current result is enough for me.
      
      2.  Not all devices work on Pegasos, i tried my Genuis-HR6 parallel
          port scanner and parallel ZIP drive and both of them don't work.  ZIP
          drive is detected properly but then suddenly gets offline.  Scanner
          does not answer any command at all.  Without the patch the same thing
          happens.  Obviously Pegasos has some more problems which are not
          discovered and not fixed yet.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1eccda34
    • Stelian Pop's avatar
      4a5f5e21
  13. 30 Oct, 2004 1 commit
  14. 29 Oct, 2004 1 commit
  15. 28 Oct, 2004 2 commits
  16. 26 Oct, 2004 1 commit
  17. 20 Oct, 2004 2 commits
  18. 19 Oct, 2004 1 commit
  19. 18 Oct, 2004 1 commit
  20. 03 Oct, 2004 2 commits
  21. 24 Sep, 2004 1 commit
  22. 17 Sep, 2004 2 commits
  23. 10 Sep, 2004 1 commit
    • John Stultz's avatar
      [PATCH] USB: early usb handoff for 2.6 · a83b8e19
      John Stultz authored
              Apparently there is an issue w/ the IBM x440/x445's BIOS's USB
      Legacy support. Due to the delay in issuing SMI's across the IOAPICs,
      its possible for I/O to ports 60/64 to cause register corruption.
      
      The solution is to disable the BIOS's USB Legacy support early in
      boot(via PCI quirks) for x440/x445 systems.
      
      Originally written by Vojtech against SuSE's tree, this patch was then
      updated to disable EHCI by Aleksey Gorelov, cleaned up by Pete Zaitcev
      for 2.4 and finally tweaked and updated against 2.6 by me.
      
      I've lightly tested this version of the patch, but it differs little
      from what Aleksey, Pete and I have been testing for 2.4.
      Signed-off-by: default avatarJohn Stultz <jstultz@us.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      a83b8e19
  24. 01 Sep, 2004 1 commit
  25. 27 Aug, 2004 1 commit
    • Arjan van de Ven's avatar
      [PATCH] schedule profileing · f0fd8a8d
      Arjan van de Ven authored
      From: William Lee Irwin III <wli@holomorphy.com>
      
      The patch (from Ingo) below is quite interesting, it allows the use of
      readprofile not for statistical tine sampling, but for seeing where calls to
      schedule() come from, so it can give some insight to the "where do my context
      switches come from" question.
      
      Boot with `profile=schedul2' to activate this feature.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f0fd8a8d
  26. 24 Aug, 2004 1 commit
  27. 23 Aug, 2004 2 commits
  28. 17 Aug, 2004 1 commit
  29. 11 Jul, 2004 1 commit
  30. 05 Jul, 2004 1 commit