1. 30 1月, 2008 3 次提交
  2. 20 10月, 2007 3 次提交
  3. 19 10月, 2007 3 次提交
  4. 18 10月, 2007 2 次提交
    • A
      x86: remove duplicated vsyscall nsec update · c861eff8
      Andi Kleen 提交于
      Spotted by Chuck Ebbert
      
      [ tglx: arch/x86 adaptation ]
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      c861eff8
    • M
      x86: fix cpu_to_node references · 98c9e27a
      Mike Travis 提交于
      In x86_64 and i386 architectures most arrays that are sized using
      NR_CPUS lay in local memory on node 0.  Not only will most (99%?) of the
      systems not use all the slots in these arrays, particularly when NR_CPUS
      is increased to accommodate future very high cpu count systems, but a
      number of cache lines are passed unnecessarily on the system bus when
      these arrays are referenced by cpus on other nodes.
      
      Typically, the values in these arrays are referenced by the cpu
      accessing it's own values, though when passing IPI interrupts, the cpu
      does access the data relevant to the targeted cpu/node.  Of course, if
      the referencing cpu is not on node 0, then the reference will still
      require cross node exchanges of cache lines.  A common use of this is
      for an interrupt service routine to pass the interrupt to other cpus
      local to that node.
      
      Ideally, all the elements in these arrays should be moved to the per_cpu
      data area.  In some cases (such as x86_cpu_to_apicid) the array is
      referenced before the per_cpu data areas are setup.  In this case, a
      static array is declared in the __initdata area and initialized by the
      booting cpu (BSP).  The values are then moved to the per_cpu area after
      it is initialized and the original static array is freed with the rest
      of the __initdata.
      
      This patch:
      
      Fix four instances where cpu_to_node is referenced by array instead of
      via the cpu_to_node macro.  This is preparation to moving it to the
      per_cpu data area.
      Signed-off-by: NMike Travis <travis@sgi.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      98c9e27a
  5. 14 10月, 2007 1 次提交
    • D
      Delete filenames in comments. · 835c34a1
      Dave Jones 提交于
      Since the x86 merge, lots of files that referenced their own filenames
      are no longer correct.  Rather than keep them up to date, just delete
      them, as they add no real value.
      
      Additionally:
      - fix up comment formatting in scx200_32.c
      - Remove a credit from myself in setup_64.c from a time when we had no SCM
      - remove longwinded history from tsc_32.c which can be figured out from
        git.
      Signed-off-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      835c34a1
  6. 11 10月, 2007 2 次提交
  7. 22 7月, 2007 1 次提交
    • A
      x86_64: Add vDSO for x86-64 with gettimeofday/clock_gettime/getcpu · 2aae950b
      Andi Kleen 提交于
      This implements new vDSO for x86-64.  The concept is similar
      to the existing vDSOs on i386 and PPC.  x86-64 has had static
      vsyscalls before,  but these are not flexible enough anymore.
      
      A vDSO is a ELF shared library supplied by the kernel that is mapped into
      user address space.  The vDSO mapping is randomized for each process
      for security reasons.
      
      Doing this was needed for clock_gettime, because clock_gettime
      always needs a syscall fallback and having one at a fixed
      address would have made buffer overflow exploits too easy to write.
      
      The vdso can be disabled with vdso=0
      
      It currently includes a new gettimeofday implemention and optimized
      clock_gettime(). The gettimeofday implementation is slightly faster
      than the one in the old vsyscall.  clock_gettime is significantly faster
      than the syscall for CLOCK_MONOTONIC and CLOCK_REALTIME.
      
      The new calls are generally faster than the old vsyscall.
      
      Advantages over the old x86-64 vsyscalls:
      - Extensible
      - Randomized
      - Cleaner
      - Easier to virtualize (the old static address range previously causes
      overhead e.g. for Xen because it has to create special page tables for it)
      
      Weak points:
      - glibc support still to be written
      
      The VM interface is partly based on Ingo Molnar's i386 version.
      
      Includes compile fix from Joachim Deguara
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2aae950b
  8. 22 5月, 2007 1 次提交
    • J
      x86_64: vsyscall time() fix · d0aff6e6
      john stultz 提交于
      The vsyscall time() function basically returns the second portion of
      xtime directly.  This however means that there is about a ticks worth of
      time each second where time() will return a second value less then what
      gettimeofday() does.
      
      Additionally, this window where vtime() is behind vgettimeofday() grows
      when dynticks is enabled, so its probably good to get this in before
      dynticks lands.
      
      Big thanks to Sripathi for noticing this issue and creating a test case
      to work with!
      
      This patch changes the vtime() implemenation to call vgettimeofday(),
      much as syscall time() implementation calls gettimeofday().
      
      2.6.21 stable candidate too
      Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d0aff6e6
  9. 10 5月, 2007 1 次提交
    • R
      Add suspend-related notifications for CPU hotplug · 8bb78442
      Rafael J. Wysocki 提交于
      Since nonboot CPUs are now disabled after tasks and devices have been
      frozen and the CPU hotplug infrastructure is used for this purpose, we need
      special CPU hotplug notifications that will help the CPU-hotplug-aware
      subsystems distinguish normal CPU hotplug events from CPU hotplug events
      related to a system-wide suspend or resume operation in progress.  This
      patch introduces such notifications and causes them to be used during
      suspend and resume transitions.  It also changes all of the
      CPU-hotplug-aware subsystems to take these notifications into consideration
      (for now they are handled in the same way as the corresponding "normal"
      ones).
      
      [oleg@tv-sign.ru: cleanups]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8bb78442
  10. 03 5月, 2007 3 次提交
    • E
      [PATCH] x86-64: vsyscall_gtod_data diet and vgettimeofday() fix · c8118c6c
      Eric Dumazet 提交于
      Current vsyscall_gtod_data is large (3 or 4 cache lines dirtied at timer
      interrupt). We can shrink it to exactly 64 bytes (1 cache line on AMD64)
      
      Instead of copying a whole struct clocksource, we copy only needed fields.
      
      I deleted an unused field : offset_base
      
      This patch fixes one oddity in vgettimeofday(): It can returns a timeval with
      tv_usec = 1000000. Maybe not a bug, but why not doing the right thing ?
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      c8118c6c
    • E
      [PATCH] x86-64: fix vtime() vsyscall · 272a3713
      Eric Dumazet 提交于
      There is a tiny probability that the return value from vtime(time_t *t) is
      Signed-off-by: NAndi Kleen <ak@suse.de>
      
      different than the value stored in *t
      
      Using a temporary variable solves the problem and gives a faster code.
      
         17:   48 85 ff                test   %rdi,%rdi
         1a:   48 8b 05 00 00 00 00    mov    0(%rip),%rax        #
      __vsyscall_gtod_data.wall_time_tv.tv_sec
         21:   74 03                   je     26
         23:   48 89 07                mov    %rax,(%rdi)
         26:   c9                      leaveq
         27:   c3                      retq
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      272a3713
    • V
      [PATCH] x86: __pa and __pa_symbol address space separation · 0dbf7028
      Vivek Goyal 提交于
      Currently __pa_symbol is for use with symbols in the kernel address
      map and __pa is for use with pointers into the physical memory map.
      But the code is implemented so you can usually interchange the two.
      
      __pa which is much more common can be implemented much more cheaply
      if it is it doesn't have to worry about any other kernel address
      spaces.  This is especially true with a relocatable kernel as
      __pa_symbol needs to peform an extra variable read to resolve
      the address.
      
      There is a third macro that is added for the vsyscall data
      __pa_vsymbol for finding the physical addesses of vsyscall pages.
      
      Most of this patch is simply sorting through the references to
      __pa or __pa_symbol and using the proper one.  A little of
      it is continuing to use a physical address when we have it
      instead of recalculating it several times.
      
      swapper_pgd is now NULL.  leave_mm now uses init_mm.pgd
      and init_mm.pgd is initialized at boot (instead of compile time)
      to the physmem virtual mapping of init_level4_pgd.  The
      physical address changed.
      
      Except for the for EMPTY_ZERO page all of the remaining references
      to __pa_symbol appear to be during kernel initialization.  So this
      should reduce the cost of __pa in the common case, even on a relocated
      kernel.
      
      As this is technically a semantic change we need to be on the lookout
      for anything I missed.  But it works for me (tm).
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      0dbf7028
  11. 15 3月, 2007 1 次提交
  12. 17 2月, 2007 1 次提交
  13. 15 2月, 2007 2 次提交
  14. 11 12月, 2006 1 次提交
  15. 08 12月, 2006 2 次提交
  16. 07 12月, 2006 1 次提交
    • E
      [PATCH] x86-64: fix perms/range of vsyscall vma in /proc/*/maps · 103efcd9
      Ernie Petrides 提交于
      The final line of /proc/<pid>/maps on x86_64 for native 64-bit
      tasks shows an incorrect ending address and incorrect permissions.  There
      is only a single page mapped in this vsyscall region, and it is accessible
      for both read and execute.
      
      The patch below fixes this.  (Since 32-bit-compat tasks have a real vma
      with correct perms/range, no change is necessary for that scenario.)
      
      Before the patch, a "cat /proc/self/maps | tail -1" shows this:
      
              ffffffffff600000-ffffffffffe00000 ---p 00000000 [...]
      
      After the patch, this is the output:
      
              ffffffffff600000-ffffffffff601000 r-xp 00000000 [...]
      Signed-off-by: NErnie Petrides <petrides@redhat.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      103efcd9
  17. 17 11月, 2006 1 次提交
  18. 14 11月, 2006 1 次提交
    • A
      [PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled · 8c131af1
      Andi Kleen 提交于
      The vgetcpu per CPU initialization previously relied on CPU hotplug
      events for all CPUs to initialize the per CPU state. That only
      worked only on kernels with CONFIG_HOTPLUG_CPU enabled.  On the
      others some CPUs didn't get their state initialized properly
      and vgetcpu wouldn't work.
      
      Change the initialization sequence to instead run in a normal
      initcall (which runs after the normal CPU bootup) and initialize
      all running CPUs there. Later hotplug CPUs are still handled
      with an hotplug notifier.
      
      This actually simplifies the code somewhat.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      8c131af1
  19. 01 10月, 2006 1 次提交
    • A
      [PATCH] kill wall_jiffies · 8ef38609
      Atsushi Nemoto 提交于
      With 2.6.18-rc4-mm2, now wall_jiffies will always be the same as jiffies.
      So we can kill wall_jiffies completely.
      
      This is just a cleanup and logically should not change any real behavior
      except for one thing: RTC updating code in (old) ppc and xtensa use a
      condition "jiffies - wall_jiffies == 1".  This condition is never met so I
      suppose it is just a bug.  I just remove that condition only instead of
      kill the whole "if" block.
      
      [heiko.carstens@de.ibm.com: s390 build fix and cleanup]
      Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Hirokazu Takata <takata.hirokazu@renesas.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kazumoto Kojima <kkojima@rr.iij4u.or.jp>
      Cc: Richard Curnow <rc@rc0.org.uk>
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8ef38609
  20. 30 9月, 2006 1 次提交
  21. 26 9月, 2006 2 次提交
    • A
      [PATCH] Add sparse annotation to vsyscall.c · 131cfd7b
      Andi Kleen 提交于
      Fixes
      
      linux/arch/x86_64/kernel/vsyscall.c:276:7: warning: constant 0x0f40000000000 is so big it is long
      linux/arch/x86_64/kernel/vsyscall.c:80:14: warning: incorrect type in argument 1 (different address spaces)
      linux/arch/x86_64/kernel/vsyscall.c:80:14:    expected void const volatile [noderef] *addr<asn:2>
      linux/arch/x86_64/kernel/vsyscall.c:80:14:    got void *<noident>
      linux/arch/x86_64/kernel/vsyscall.c:200:7: warning: incorrect type in assignment (different address spaces)
      linux/arch/x86_64/kernel/vsyscall.c:200:7:    expected unsigned short [usertype] *map1
      linux/arch/x86_64/kernel/vsyscall.c:200:7:    got void [noderef] *<asn:2>
      linux/arch/x86_64/kernel/vsyscall.c:203:7: warning: incorrect type in assignment (different address spaces)
      linux/arch/x86_64/kernel/vsyscall.c:203:7:    expected unsigned short [usertype] *map2
      linux/arch/x86_64/kernel/vsyscall.c:203:7:    got void [noderef] *<asn:2>
      linux/arch/x86_64/kernel/vsyscall.c:215:10: warning: incorrect type in argument 1 (different address spaces)
      linux/arch/x86_64/kernel/vsyscall.c:215:10:    expected void volatile [noderef] *addr<asn:2>
      linux/arch/x86_64/kernel/vsyscall.c:215:10:    got unsigned short [usertype] *map2
      linux/arch/x86_64/kernel/vsyscall.c:217:10: warning: incorrect type in argument 1 (different address spaces)
      linux/arch/x86_64/kernel/vsyscall.c:217:10:    expected void volatile [noderef] *addr<asn:2>
      linux/arch/x86_64/kernel/vsyscall.c:217:10:    got unsigned short [usertype] *map1
      Signed-off-by: NAndi Kleen <ak@suse.de>
      131cfd7b
    • V
      [PATCH] Add the vgetcpu vsyscall · c08c8205
      Vojtech Pavlik 提交于
      This patch adds a vgetcpu vsyscall, which depending on the CPU RDTSCP
      capability uses either the RDTSCP or CPUID to obtain a CPU and node
      numbers and pass them to the program.
      
      AK: Lots of changes over Vojtech's original code:
      Better prototype for vgetcpu()
      It's better to pass the cpu / node numbers as separate arguments
      to avoid mistakes when going from SMP to NUMA.
      Also add a fast time stamp based cache using a user supplied
      argument to speed things more up.
      Use fast method from Chuck Ebbert to retrieve node/cpu from
      GDT limit instead of CPUID
      Made sure RDTSCP init is always executed after node is known.
      Drop printk
      Signed-off-by: NVojtech Pavlik <vojtech@suse.cz>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      c08c8205
  22. 27 6月, 2006 1 次提交
  23. 12 1月, 2006 2 次提交
  24. 13 9月, 2005 1 次提交
  25. 17 5月, 2005 2 次提交
    • A
      [PATCH] x86_64: Make vsyscall.c compile without CONFIG_SYSCTL · f3c5f5e7
      Andi Kleen 提交于
      Originally from Matt Tolentino
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f3c5f5e7
    • A
      [PATCH] x86_64: Add pmtimer support · 312df5f1
      Andi Kleen 提交于
      There are unfortunately more and more multi processor Opteron systems which
      don't have HPET timer support in the southbridge.  This covers in particular
      Nvidia and VIA chipsets.  They also don't guarantee that the TSCs are
      synchronized between CPUs; and especially with MP powernow the systems are
      nearly unusable because the time gets very inconsistent between CPUs.
      
      The timer code for x86-64 was originally written under the assumption that we
      could fall back to the HPET timer on such systems.  But this doesn't work
      there.
      
      Another alternative is to use the ACPI PM timer as primary time source.  This
      patch does that.  The kernel only uses PM timer when there is no other choice
      because it has some disadvantages.
      
      Ported over from i386.  It should be faster than the i386 version because I
      dropped the "read three times" workaround, but is still considerable slower
      than HPET and also does not work together with vsyscalls which have to be
      disabled.
      
      Cc: <mark.langsdorf@amd.com>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      312df5f1