16 Feb, 2006

1 commit

  • Make new MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK consistent across all
    arches. The idea is to make it possible to use them portably even before
    distros include them in libc headers.

    Move common flags to asm-generic/mman.h

    Signed-off-by: Michael S. Tsirkin
    Cc: Roland Dreier
    Cc: Badari Pulavarty
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael S. Tsirkin
     

15 Feb, 2006

7 commits

  • Currently, copy-on-write may change the physical address of a page even if the
    user requested that the page is pinned in memory (either by mlock or by
    get_user_pages). This happens if the process forks meanwhile, and the parent
    writes to that page. As a result, the page is orphaned: in case of
    get_user_pages, the application will never see any data hardware DMA's into
    this page after the COW. In case of mlock'd memory, the parent is not getting
    the realtime/security benefits of mlock.

    In particular, this affects the Infiniband modules which do DMA from and into
    user pages all the time.

    This patch adds madvise options to control whether memory range is inherited
    across fork. Useful e.g. for when hardware is doing DMA from/into these
    pages. Could also be useful to an application wanting to speed up its forks
    by cutting large areas out of consideration.

    Signed-off-by: Michael S. Tsirkin
    Acked-by: Hugh Dickins
    Cc: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael S. Tsirkin
     
  • Signed-off-by: Maciej W. Rozycki
    Signed-off-by: Ralf Baechle

    Maciej W. Rozycki
     
  • Signed-off-by: Ralf Baechle

    Ralf Baechle
     
  • From Richard Sandiford :

    This patch caused a miscompilation of the restore_gp_regs() block
    in restore_sigcontext(). This was in a 32-bit kernel compiled with
    GCC CVS head.

    restore_gp_regs() copies 64-bit user fields into 32-bit variables,
    and in this combination, the new __get_user_asm_ll32() clobbers too
    many registers. It says:

    /*
    * Get a long long 64 using 32 bit registers.
    */
    { \
    __asm__ __volatile__( \
    "1: lw %1, (%3) \n" \
    "2: lw %D1, 4(%3) \n" \
    " move %0, $0 \n" \
    "3: .section .fixup,\"ax\" \n" \
    "4: li %0, %4 \n" \
    " move %1, $0 \n" \
    " move %D1, $0 \n" \
    " j 3b \n" \
    " .previous \n" \
    " .section __ex_table,\"a\" \n" \
    " " __UA_ADDR " 1b, 4b \n" \
    " " __UA_ADDR " 2b, 4b \n" \
    " .previous \n" \
    : "=r" (__gu_err), "=&r" (val) \
    : "0" (0), "r" (addr), "i" (-EFAULT)); \
    }

    and this requires val (%1) to be a 64-bit value. In the case I saw,
    gcc was using $3 for the 32-bit val, and wasn't expecting $4 to be
    clobbered.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     
  • Add blast_xxx_range(), protected_blast_xxx_range() etc. for common
    use. They are built by __BUILD_BLAST_CACHE_RANGE().
    Use protected_cache_op() macro for various protected_ routines.
    Output code should be logically same.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Ralf Baechle

    Atsushi Nemoto
     
  • Signed-off-by: Ralf Baechle

    Ralf Baechle
     
  • So we can get rid of config.h and the #ifdef crapola in the generic
    timex.h.

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     

09 Feb, 2006

5 commits


08 Feb, 2006

2 commits


07 Feb, 2006

16 commits


13 Jan, 2006

5 commits

  • {get,put}_thread_info() were introduced in 2.5.4 and never
    had been called by anything in the tree.

    Signed-off-by: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • Signed-off-by: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Al Viro
     
  • )

    From: Ingo Molnar

    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: Ingo Molnar
    Signed-off-by: Ashok Raj
    Signed-off-by: Ken Chen
    Cc:
    Signed-off-by: John Hawkes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    akpm@osdl.org
     
  • Add per-arch sched_cacheflush() which is a write-back cacheflush used by
    the migration-cost calibration code at bootup time.

    Signed-off-by: Ingo Molnar
    Cc: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ingo Molnar
     

10 Jan, 2006

4 commits

  • Gcc has a tradition of misscompiling the previous construct using the
    address of a label as argument to inline assembler. Gas otoh has the
    annoying difference between la and dla which are only usable for 32-bit
    rsp. 64-bit code, so can't be used without conditional compilation.
    The alterantive is switching the assembler to 64-bit code which happens
    to work right even for 32-bit code ...

    Signed-off-by: Ralf Baechle

    Ralf Baechle
     
  • local_irq_restore uses di which saves the whole status content, not
    just the IE bit resulting in local_irq_restore() to fail. This only
    happens if both CONFIG_CPU_MIPSR2 and CONFIG_IRQ_CPU are enabled.

    Signed-off-by: Maxime Bizon
    Signed-off-by: Ralf Baechle

    Maxime Bizon
     
  • dump_regs() is used by a bunch of drivers for their internal stuff;
    renamed mips instance (one that is seen in system-wide headers)
    to elf_dump_regs()

    Signed-off-by: Al Viro
    Signed-off-by: Ralf Baechle

    Al Viro
     
  • USB OpenHCI host controller on Au1550 only decodes memory addresses from
    0x14020000 to 0x1407FFFF according to the databook, which gives 0x60000
    (on the prior Au1x00 chips the map size was 1MB).

    Signed-off-by: Sergei Shtylyov
    Acked-by: Jordan Crouse
    Signed-off-by: Ralf Baechle

    Sergei Shtylyov