1. 12 Jan, 2006 2 commits
    • akpm@osdl.org's avatar
      [PATCH] scheduler cache-hot-autodetect · 198e2f18
      akpm@osdl.org authored
      
      
      )
      
      From: Ingo Molnar <mingo@elte.hu>
      
      This is the latest version of the scheduler cache-hot-auto-tune patch.
      
      The first problem was that detection time scaled with O(N^2), which is
      unacceptable on larger SMP and NUMA systems. To solve this:
      
      - I've added a 'domain distance' function, which is used to cache
        measurement results. Each distance is only measured once. This means
        that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT
        distances 0 and 1, and on SMP distance 0 is measured. The code walks
        the domain tree to determine the distance, so it automatically follows
        whatever hierarchy an architecture sets up. This cuts down on the boot
        time significantly and removes the O(N^2) limit. The only assumption
        is that migration costs can be expressed as a function of domain
        distance - this covers the overwhelming majority of existing systems,
        and is a good guess even for more assymetric systems.
      
        [ People hacking systems that have assymetries that break this
          assumption (e.g. different CPU speeds) should experiment a bit with
          the cpu_distance() function. Adding a ->migration_distance factor to
          the domain structure would be one possible solution - but lets first
          see the problem systems, if they exist at all. Lets not overdesign. ]
      
      Another problem was that only a single cache-size was used for measuring
      the cost of migration, and most architectures didnt set that variable
      up. Furthermore, a single cache-size does not fit NUMA hierarchies with
      L3 caches and does not fit HT setups, where different CPUs will often
      have different 'effective cache sizes'. To solve this problem:
      
      - Instead of relying on a single cache-size provided by the platform and
        sticking to it, the code now auto-detects the 'effective migration
        cost' between two measured CPUs, via iterating through a wide range of
        cachesizes. The code searches for the maximum migration cost, which
        occurs when the working set of the test-workload falls just below the
        'effective cache size'. I.e. real-life optimized search is done for
        the maximum migration cost, between two real CPUs.
      
        This, amongst other things, has the positive effect hat if e.g. two
        CPUs share a L2/L3 cache, a different (and accurate) migration cost
        will be found than between two CPUs on the same system that dont share
        any caches.
      
      (The reliable measurement of migration costs is tricky - see the source
      for details.)
      
      Furthermore i've added various boot-time options to override/tune
      migration behavior.
      
      Firstly, there's a blanket override for autodetection:
      
      	migration_cost=1000,2000,3000
      
      will override the depth 0/1/2 values with 1msec/2msec/3msec values.
      
      Secondly, there's a global factor that can be used to increase (or
      decrease) the autodetected values:
      
      	migration_factor=120
      
      will increase the autodetected values by 20%. This option is useful to
      tune things in a workload-dependent way - e.g. if a workload is
      cache-insensitive then CPU utilization can be maximized by specifying
      migration_factor=0.
      
      I've tested the autodetection code quite extensively on x86, on 3
      P3/Xeon/2MB, and the autodetected values look pretty good:
      
      Dual Celeron (128K L2 cache):
      
       ---------------------
       migration cost matrix (max_cache_size: 131072, cpu: 467 MHz):
       ---------------------
                 [00]    [01]
       [00]:     -     1.7(1)
       [01]:   1.7(1)    -
       ---------------------
       cacheflush times [2]: 0.0 (0) 1.7 (1784008)
       ---------------------
      
      Here the slow memory subsystem dominates system performance, and even
      though caches are small, the migration cost is 1.7 msecs.
      
      Dual HT P4 (512K L2 cache):
      
       ---------------------
       migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz):
       ---------------------
                 [00]    [01]    [02]    [03]
       [00]:     -     0.4(1)  0.0(0)  0.4(1)
       [01]:   0.4(1)    -     0.4(1)  0.0(0)
       [02]:   0.0(0)  0.4(1)    -     0.4(1)
       [03]:   0.4(1)  0.0(0)  0.4(1)    -
       ---------------------
       cacheflush times [2]: 0.0 (33900) 0.4 (448514)
       ---------------------
      
      Here it can be seen that there is no migration cost between two HT
      siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory
      system makes inter-physical-CPU migration pretty cheap: 0.4 msecs.
      
      8-way P3/Xeon [2MB L2 cache]:
      
       ---------------------
       migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz):
       ---------------------
                 [00]    [01]    [02]    [03]    [04]    [05]    [06]    [07]
       [00]:     -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [01]:  19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [02]:  19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [03]:  19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1) 19.2(1)
       [04]:  19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1) 19.2(1)
       [05]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1) 19.2(1)
       [06]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -    19.2(1)
       [07]:  19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1)    -
       ---------------------
       cacheflush times [2]: 0.0 (0) 19.2 (19281756)
       ---------------------
      
      This one has huge caches and a relatively slow memory subsystem - so the
      migration cost is 19 msecs.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarKen Chen <kenneth.w.chen@intel.com>
      Cc: <wilder@us.ibm.com>
      Signed-off-by: default avatarJohn Hawkes <hawkes@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      198e2f18
    • Ingo Molnar's avatar
      [PATCH] sched: add cacheflush() asm · 4dc7a0bb
      Ingo Molnar authored
      
      
      Add per-arch sched_cacheflush() which is a write-back cacheflush used by
      the migration-cost calibration code at bootup time.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4dc7a0bb
  2. 05 Jan, 2006 1 commit
  3. 07 Dec, 2005 1 commit
    • Venkatesh Pallipadi's avatar
      [CPUFREQ] CPU frequency display in /proc/cpuinfo · 95235ca2
      Venkatesh Pallipadi authored
      
      
      What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of
      changing frequency?
      
      Today the answer is: It depends.
      On i386:
      SMP kernel - It is always the boot frequency
      UP kernel - Scales with the frequency change and shows that was last set.
      
      On x86_64:
      There is one single variable cpu_khz that gets written by all the CPUs. So,
      the frequency set by last CPU will be seen on /proc/cpuinfo of all the
      CPUs in the system. What you see also depends on whether you have constant_tsc
      capable CPU or not.
      
      On ia64:
      It is always boot time frequency of a particular CPU that gets displayed.
      
      The patch below changes this to:
      Show the last known frequency of the particular CPU, when cpufreq is present. If
      cpu doesnot support changing of frequency through cpufreq, then boot frequency
      will be shown. The patch affects i386, x86_64 and ia64 architectures.
      
      Signed-off-by: Venkatesh Pallipadi<venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      95235ca2
  4. 07 Nov, 2005 1 commit
  5. 31 Oct, 2005 1 commit
  6. 25 Oct, 2005 1 commit
  7. 28 Sep, 2005 1 commit
  8. 19 Sep, 2005 2 commits
  9. 08 Sep, 2005 1 commit
    • Tony Luck's avatar
      [IA64] simplified efi memory map parsing · d8c97d5f
      Tony Luck authored
      
      
      New version leaves the original memory map unmodified.
      Also saves any granule trimmings for use by the uncached
      memory allocator.
      
      Inspired by Khalid Aziz (various traces of his patch still
      remain).  Fixes to uncached_build_memmap() and sn2 testing
      by Martin Hicks.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      d8c97d5f
  10. 24 Aug, 2005 1 commit
  11. 12 Jul, 2005 2 commits
  12. 28 Jun, 2005 1 commit
    • Mark Maule's avatar
      [IA64-SGI] pcdp: add PCDP pci interface support · 66b7f8a3
      Mark Maule authored
      
      
      Resend 2 with changes per Bjorn Helgaas comments.  Changes from original:
      
      + Change globals to vga_console_iobase/vga_console_membase and make them
        unconditional.
      + Address style-related comments.
      
      Patch to extend the PCDP vga setup code to support PCI io/mem translations
      for the legacy vga ioport and ram spaces on architectures (e.g. altix) which
      need them.
      
      Summary of the changes:
      
      drivers/firmware/pcdp.c
      drivers/firmware/pcdp.h
      -----------------------
      + add declaration for the spec-defined PCI interface struct (pcdp_if_pci)
        as well as support macros.
      
      + extend setup_vga_console() to know about pcdp_if_pci and add a couple of
        globals to hold the io and mem translation offsets if present.
      
      arch/ia64/kernel/setup.c
      ------------------------
      + tweek early_console_setup() to allow multiple early console setup routines
        to be called.
      
      include/asm-ia64/vga.h
      ----------------------
      + make VGA_MAP_MEM vga_console_membase aware
      Signed-off-by: default avatarMark Maule <maule@sgi.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      66b7f8a3
  13. 08 Jun, 2005 1 commit
  14. 25 Apr, 2005 2 commits
  15. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4