1. 02 8月, 2005 4 次提交
    • K
      [PATCH] ppc32: Mark boards that don't build as BROKEN · e8be1c8e
      Kumar Gala 提交于
      Marked APUS and GEMINI as BROKEN since they do not build at the platform
      level.  We have requested that the maintainers of these boards/platforms
      fix them by the time 2.6.15 is released or we plan on concerning them
      unmaintained and thus removing them.
      Signed-off-by: NKumar Gala <kumar.gala@freescale.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e8be1c8e
    • B
      [PATCH] ppc64: Fix CONFIG_ALTIVEC not set · 57ee67af
      Benjamin Herrenschmidt 提交于
      The code that sets the altivec capability of the CPU based on firmware
      informations can enable altivec when the kernel has CONFIG_ALTIVEC
      disabled.  This results in "interesting" crashes.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      57ee67af
    • E
      [PATCH] disable addres space randomization default on transmeta CPUs · cdf32eaa
      Eric Lammerts 提交于
      We know that the randomisation slows down some workloads on Transmeta CPUs
      by quite large amounts.  We think it's because the CPU needs to recode the
      same x86 instructions when they pop up at a different virtual address after
      a fork+exec.
      
      So disable randomization by default on those CPUs.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cdf32eaa
    • I
      [PATCH] remove sys_set_zone_reclaim() · 6cb54819
      Ingo Molnar 提交于
      This removes sys_set_zone_reclaim() for now.  While i'm sure Martin is
      trying to solve a real problem, we must not hard-code an incomplete and
      insufficient approach into a syscall, because syscalls are pretty much
      for eternity.  I am quite strongly convinced that this syscall must not
      hit v2.6.13 in its current form.
      
      Firstly, the syscall lacks basic syscall design: e.g. it allows the
      global setting of VM policy for unprivileged users. (!) [ Imagine an
      Oracle installation and a SAP installation on the same NUMA box fighting
      over the 'optimal' setting for this flag. What will they do? Will they
      try to set the flag to their own preferred value every second or so? ]
      
      Secondly, it was added based on a single datapoint from Martin:
      
       http://marc.theaimsgroup.com/?l=linux-mm&m=111763597218177&w=2
      
      where Martin characterizes the numbers the following way:
      
       ' Run-to-run variability for "make -j" is huge, so these numbers aren't
         terribly useful except to see that with reclaim the benchmark still
         finishes in a reasonable amount of time. '
      
      in other words: the fundamental problem has likely not been solved, only
      a tendential move into the right direction has been observed, and a
      handful of numbers were picked out of a set of hugely variable results,
      without showing the variability data. How much variance is there
      run-to-run?
      
      I'd really suggest to first walk the walk and see what's needed to get
      stable & predictable kernel compilation numbers on that NUMA box, before
      adding random syscalls to tune a particular aspect of the VM ... which
      approach might not even matter once the whole picture has been analyzed
      and understood!
      
      The third, most important point is that the syscall exposes VM tuning
      internals in a completely unstructured way. What sense does it make to
      have a _GLOBAL_ per-node setting for 'should we go to another node for
      reclaim'? If then it might make sense to do this per-app, via numalib or
      so.
      
      The change is minimalistic in that it doesnt remove the syscall and the
      underlying infrastructure changes, only the user-visible changes.  We
      could perhaps add a CAP_SYS_ADMIN-only sysctl for this hack, a'ka
      /proc/sys/vm/swappiness, but even that looks quite counterproductive
      when the generic approach is that we are trying to reduce the number of
      external factors in the VM balance picture.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6cb54819
  2. 31 7月, 2005 5 次提交
  3. 30 7月, 2005 14 次提交
  4. 29 7月, 2005 17 次提交