1. 01 3月, 2010 1 次提交
    • A
      KVM: PPC: Use PACA backed shadow vcpu · 7e57cba0
      Alexander Graf 提交于
      We're being horribly racy right now. All the entry and exit code hijacks
      random fields from the PACA that could easily be used by different code in
      case we get interrupted, for example by a #MC or even page fault.
      
      After discussing this with Ben, we figured it's best to reserve some more
      space in the PACA and just shove off some vcpu state to there.
      
      That way we can drastically improve the readability of the code, make it
      less racy and less complex.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NAvi Kivity <avi@redhat.com>
      7e57cba0
  2. 05 11月, 2009 1 次提交
  3. 21 9月, 2009 2 次提交
    • I
      perf: Tidy up after the big rename · 57c0c15b
      Ingo Molnar 提交于
       - provide compatibility Kconfig entry for existing PERF_COUNTERS .config's
      
       - provide courtesy copy of old perf_counter.h, for user-space projects
      
       - small indentation fixups
      
       - fix up MAINTAINERS
      
       - fix small x86 printout fallout
      
       - fix up small PowerPC comment fallout (use 'counter' as in register)
      Reviewed-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      57c0c15b
    • I
      perf: Do the big rename: Performance Counters -> Performance Events · cdd6c482
      Ingo Molnar 提交于
      Bye-bye Performance Counters, welcome Performance Events!
      
      In the past few months the perfcounters subsystem has grown out its
      initial role of counting hardware events, and has become (and is
      becoming) a much broader generic event enumeration, reporting, logging,
      monitoring, analysis facility.
      
      Naming its core object 'perf_counter' and naming the subsystem
      'perfcounters' has become more and more of a misnomer. With pending
      code like hw-breakpoints support the 'counter' name is less and
      less appropriate.
      
      All in one, we've decided to rename the subsystem to 'performance
      events' and to propagate this rename through all fields, variables
      and API names. (in an ABI compatible fashion)
      
      The word 'event' is also a bit shorter than 'counter' - which makes
      it slightly more convenient to write/handle as well.
      
      Thanks goes to Stephane Eranian who first observed this misnomer and
      suggested a rename.
      
      User-space tooling and ABI compatibility is not affected - this patch
      should be function-invariant. (Also, defconfigs were not touched to
      keep the size down.)
      
      This patch has been generated via the following script:
      
        FILES=$(find * -type f | grep -vE 'oprofile|[^K]config')
      
        sed -i \
          -e 's/PERF_EVENT_/PERF_RECORD_/g' \
          -e 's/PERF_COUNTER/PERF_EVENT/g' \
          -e 's/perf_counter/perf_event/g' \
          -e 's/nb_counters/nb_events/g' \
          -e 's/swcounter/swevent/g' \
          -e 's/tpcounter_event/tp_event/g' \
          $FILES
      
        for N in $(find . -name perf_counter.[ch]); do
          M=$(echo $N | sed 's/perf_counter/perf_event/g')
          mv $N $M
        done
      
        FILES=$(find . -name perf_event.*)
      
        sed -i \
          -e 's/COUNTER_MASK/REG_MASK/g' \
          -e 's/COUNTER/EVENT/g' \
          -e 's/\<event\>/event_id/g' \
          -e 's/counter/event/g' \
          -e 's/Counter/Event/g' \
          $FILES
      
      ... to keep it as correct as possible. This script can also be
      used by anyone who has pending perfcounters patches - it converts
      a Linux kernel tree over to the new naming. We tried to time this
      change to the point in time where the amount of pending patches
      is the smallest: the end of the merge window.
      
      Namespace clashes were fixed up in a preparatory patch - and some
      stylistic fallout will be fixed up in a subsequent patch.
      
      ( NOTE: 'counters' are still the proper terminology when we deal
        with hardware registers - and these sed scripts are a bit
        over-eager in renaming them. I've undone some of that, but
        in case there's something left where 'counter' would be
        better than 'event' we can undo that on an individual basis
        instead of touching an otherwise nicely automated patch. )
      Suggested-by: NStephane Eranian <eranian@google.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NPaul Mackerras <paulus@samba.org>
      Reviewed-by: NArjan van de Ven <arjan@linux.intel.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux-arch@vger.kernel.org>
      LKML-Reference: <new-submission>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cdd6c482
  4. 20 8月, 2009 1 次提交
  5. 09 6月, 2009 1 次提交
  6. 09 1月, 2009 1 次提交
    • P
      powerpc: Provide a way to defer perf counter work until interrupts are enabled · 93a6d3ce
      Paul Mackerras 提交于
      Because 64-bit powerpc uses lazy (soft) interrupt disabling, it is
      possible for a performance monitor exception to come in when the
      kernel thinks interrupts are disabled (i.e. when they are
      soft-disabled but hard-enabled).  In such a situation the performance
      monitor exception handler might have some processing to do (such as
      process wakeups) which can't be done in what is effectively an NMI
      handler.
      
      This provides a way to defer that work until interrupts get enabled,
      either in raw_local_irq_restore() or by returning from an interrupt
      handler to code that had interrupts enabled.  We have a per-processor
      flag that indicates that there is work pending to do when interrupts
      subsequently get re-enabled.  This flag is checked in the interrupt
      return path and in raw_local_irq_restore(), and if it is set,
      perf_counter_do_pending() is called to do the pending work.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      93a6d3ce
  7. 16 9月, 2008 1 次提交
    • P
      powerpc: Make it possible to move the interrupt handlers away from the kernel · 1f6a93e4
      Paul Mackerras 提交于
      This changes the way that the exception prologs transfer control to
      the handlers in 64-bit kernels with the aim of making it possible to
      have the prologs separate from the main body of the kernel.  Now,
      instead of computing the address of the handler by taking the top
      32 bits of the paca address (to get the 0xc0000000........ part) and
      ORing in something in the bottom 16 bits, we get the base address of
      the kernel by doing a load from the paca and add an offset.
      
      This also replaces an mfmsr and an ori to compute the MSR value for
      the handler with a load from the paca.  That makes it unnecessary to
      have a separate version of EXCEPTION_PROLOG_PSERIES that forces 64-bit
      mode.
      
      We can no longer use a direct branches in the exception prolog code,
      which means that the SLB miss handlers can't branch directly to
      .slb_miss_realmode any more.  Instead we have to compute the address
      and do an indirect branch.  This is conditional on CONFIG_RELOCATABLE;
      for non-relocatable kernels we use a direct branch as before.  (A later
      change will allow CONFIG_RELOCATABLE to be set on 64-bit powerpc.)
      
      Since the secondary CPUs on pSeries start execution in the first 0x100
      bytes of real memory and then have to get to wherever the kernel is,
      we can't use a direct branch to get there.  Instead this changes
      __secondary_hold_spinloop from a flag to a function pointer.  When it
      is set to a non-NULL value, the secondary CPUs jump to the function
      pointed to by that value.
      
      Finally this eliminates one code difference between 32-bit and 64-bit
      by making __secondary_hold be the text address of the secondary CPU
      spinloop rather than a function descriptor for it.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1f6a93e4
  8. 04 8月, 2008 1 次提交
  9. 24 4月, 2008 1 次提交
  10. 15 4月, 2008 1 次提交
  11. 07 2月, 2008 1 次提交
    • M
      taskstats scaled time cleanup · 06b8e878
      Michael Neuling 提交于
      This moves the ability to scale cputime into generic code.  This allows us
      to fix the issue in kernel/timer.c (noticed by Balbir) where we could only
      add an unscaled value to the scaled utime/stime.
      
      This adds a cputime_to_scaled function.  As before, the POWERPC version
      does the scaling based on the last SPURR/PURR ratio calculated.  The
      generic and s390 (only other arch to implement asm/cputime.h) versions are
      both NOPs.
      
      Also moves the SPURR and PURR snapshots closer.
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: Jay Lan <jlan@engr.sgi.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      06b8e878
  12. 20 10月, 2007 1 次提交
  13. 19 10月, 2007 1 次提交
    • M
      powerpc: add scaled time accounting · 4603ac18
      Michael Neuling 提交于
      This adds POWERPC specific hooks for scaled time accounting.
      
      POWER6 includes a SPURR register.  The SPURR is based off the PURR register
      but is scaled based on CPU frequency and issue rates.  This gives a more
      accurate account of the instructions used per task.  The PURR and timebase
      will be constant relative to the wall clock, irrespective of the CPU
      frequency.
      
      This implementation reads the SPURR register in account_system_vtime which
      is only call called on context witch and hard and soft irq entry and exit.
      The percentage of user and system time is then estimated using the ratio of
      these accounted by the PURR.  If the SPURR is not present, the PURR read.
      
      An earlier implementation of this patch read the SPURR whenever the PURR
      was read, which included the system call entry and exit path.
      Unfortunately this showed a performance regression on lmbench runs, so was
      re-implemented.
      
      I've included the lmbench results here when run bare metal on POWER6.  1st
      column is the unpatch results.  2nd column is the results using the below
      patch and the 3rd is the % diff of these results from the base.  4th and
      5th columns are the results and % differnce from the base using the older
      patch (SPURR read in syscall entry/exit path).
      
                                    Base        Scaled-Acct     SPURR-in-syscall
                                   Result      Result  % diff    Result % diff
      Simple syscall:              0.3086      0.3086  0.0000    0.3452 11.8600
      Simple read:                 0.4591      0.4671  1.7425    0.5044 9.86713
      Simple write:                0.4364      0.4366  0.0458    0.4731 8.40971
      Simple stat:                 2.0055      2.0295  1.1967    2.0669 3.06158
      Simple fstat:                0.5962      0.5876  -1.442    0.6368 6.80979
      Simple open/close:           3.1283      3.1009  -0.875    3.2088 2.57328
      Select on 10 fd's:           0.8554      0.8457  -1.133    0.8667 1.32101
      Select on 100 fd's:          3.5292      3.6329  2.9383    3.6664 3.88756
      Select on 250 fd's:          7.9097      8.1881  3.5197    8.2242 3.97613
      Select on 500 fd's:          15.2659     15.836  3.7357    15.873 3.97814
      Select on 10 tcp fd's:       0.9576      0.9416  -1.670    0.9752 1.83792
      Select on 100 tcp fd's:      7.248       7.2254  -0.311    7.2685 0.28283
      Select on 250 tcp fd's:      17.7742     17.707  -0.375    17.749 -0.1406
      Select on 500 tcp fd's:      35.4258     35.25   -0.496    35.286 -0.3929
      Signal handler installation: 0.6131      0.6075  -0.913    0.647  5.52927
      Signal handler overhead:     2.0919      2.1078  0.7600    2.1831 4.35967
      Protection fault:            0.7345      0.7478  1.8107    0.8031 9.33968
      Pipe latency:                33.006      16.398  -50.31    33.475 1.42368
      AF_UNIX sock stream latency: 14.5093     30.910  113.03    30.715 111.692
      Process fork+exit:           219.8       222.8   1.3648    229.37 4.35623
      Process fork+execve:         876.14      873.28  -0.32     868.66 -0.8533
      Process fork+/bin/sh -c:     2830        2876.5  1.6431    2958   4.52296
      File /var/tmp/XXX write bw:  1193497     1195536 0.1708    118657 -0.5799
      Pagefaults on /var/tmp/XXX:  3.1272      3.2117  2.7020    3.2521 3.99398
      
      Also, kernel compile times show no difference with this patch applied.
      
      [pbadari@us.ibm.com: Avoid unnecessary PURR reading]
      Signed-off-by: NMichael Neuling <mikey@neuling.org>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: Jay Lan <jlan@engr.sgi.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NBadari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4603ac18
  14. 03 10月, 2007 1 次提交
    • H
      [POWERPC] ppc64: support CONFIG_DEBUG_PREEMPT · 048c8bc9
      Hugh Dickins 提交于
      Add CONFIG_DEBUG_PREEMPT support to ppc64: it was useful for testing
      get_paca() preemption.  Cheat a little, just use debug_smp_processor_id()
      in the debug version of get_paca(): it contains all the right checks and
      reporting, though get_paca() doesn't really use smp_processor_id().
      
      Use local_paca for what might have been called __raw_get_paca().
      Silence harmless warnings from io.h and lparcfg.c with local_paca -
      it is okay for iseries_lparcfg_data to be referencing shared_proc
      with preemption enabled: all cpus should show the same value for
      shared_proc.
      
      Why do other architectures need TRACE_IRQFLAGS_SUPPORT for DEBUG_PREEMPT?
      I don't know, ppc64 appears to get along fine without it.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      048c8bc9
  15. 09 5月, 2007 1 次提交
    • B
      [POWERPC] Introduce address space "slices" · d0f13e3c
      Benjamin Herrenschmidt 提交于
      The basic issue is to be able to do what hugetlbfs does but with
      different page sizes for some other special filesystems; more
      specifically, my need is:
      
       - Huge pages
      
       - SPE local store mappings using 64K pages on a 4K base page size
      kernel on Cell
      
       - Some special 4K segments in 64K-page kernels for mapping a dodgy
      type of powerpc-specific infiniband hardware that requires 4K MMU
      mappings for various reasons I won't explain here.
      
      The main issues are:
      
       - To maintain/keep track of the page size per "segment" (as we can
      only have one page size per segment on powerpc, which are 256MB
      divisions of the address space).
      
       - To make sure special mappings stay within their allotted
      "segments" (including MAP_FIXED crap)
      
       - To make sure everybody else doesn't mmap/brk/grow_stack into a
      "segment" that is used for a special mapping
      
      Some of the necessary mechanisms to handle that were present in the
      hugetlbfs code, but mostly in ways not suitable for anything else.
      
      The patch relies on some changes to the generic get_unmapped_area()
      that just got merged.  It still hijacks hugetlb callbacks here or
      there as the generic code hasn't been entirely cleaned up yet but
      that shouldn't be a problem.
      
      So what is a slice ?  Well, I re-used the mechanism used formerly by our
      hugetlbfs implementation which divides the address space in
      "meta-segments" which I called "slices".  The division is done using
      256MB slices below 4G, and 1T slices above.  Thus the address space is
      divided currently into 16 "low" slices and 16 "high" slices.  (Special
      case: high slice 0 is the area between 4G and 1T).
      
      Doing so simplifies significantly the tracking of segments and avoids
      having to keep track of all the 256MB segments in the address space.
      
      While I used the "concepts" of hugetlbfs, I mostly re-implemented
      everything in a more generic way and "ported" hugetlbfs to it.
      
      Slices can have an associated page size, which is encoded in the mmu
      context and used by the SLB miss handler to set the segment sizes.  The
      hash code currently doesn't care, it has a specific check for hugepages,
      though I might add a mechanism to provide per-slice hash mapping
      functions in the future.
      
      The slice code provide a pair of "generic" get_unmapped_area() (bottomup
      and topdown) functions that should work with any slice size.  There is
      some trickiness here so I would appreciate people to have a look at the
      implementation of these and let me know if I got something wrong.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d0f13e3c
  16. 24 4月, 2007 1 次提交
  17. 21 3月, 2007 1 次提交
  18. 16 10月, 2006 1 次提交
    • P
      [POWERPC] Lazy interrupt disabling for 64-bit machines · d04c56f7
      Paul Mackerras 提交于
      This implements a lazy strategy for disabling interrupts.  This means
      that local_irq_disable() et al. just clear the 'interrupts are
      enabled' flag in the paca.  If an interrupt comes along, the interrupt
      entry code notices that interrupts are supposed to be disabled, and
      clears the EE bit in SRR1, clears the 'interrupts are hard-enabled'
      flag in the paca, and returns.  This means that interrupts only
      actually get disabled in the processor when an interrupt comes along.
      
      When interrupts are enabled by local_irq_enable() et al., the code
      sets the interrupts-enabled flag in the paca, and then checks whether
      interrupts got hard-disabled.  If so, it also sets the EE bit in the
      MSR to hard-enable the interrupts.
      
      This has the potential to improve performance, and also makes it
      easier to make a kernel that can boot on iSeries and on other 64-bit
      machines, since this lazy-disable strategy is very similar to the
      soft-disable strategy that iSeries already uses.
      
      This version renames paca->proc_enabled to paca->soft_enabled, and
      changes a couple of soft-disables in the kexec code to hard-disables,
      which should fix the crash that Michael Ellerman saw.  This doesn't
      yet use a reserved CR field for the soft_enabled and hard_enabled
      flags.  This applies on top of Stephen Rothwell's patches to make it
      possible to build a combined iSeries/other kernel.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d04c56f7
  19. 13 9月, 2006 1 次提交
    • P
      [POWERPC] Fix MMIO ops to provide expected barrier behaviour · f007cacf
      Paul Mackerras 提交于
      This changes the writeX family of functions to have a sync instruction
      before the MMIO store rather than after, because the generally expected
      behaviour is that the device receiving the MMIO store can be guaranteed
      to see the effects of any preceding writes to normal memory.
      
      To preserve ordering between writeX and readX, and to preserve ordering
      between preceding stores and the readX, the readX family of functions
      have had an sync added before the load.
      
      Although writeX followed by spin_unlock is not officially guaranteed
      to keep the writeX inside the spin-locked region unless an mmiowb()
      is used, there are currently drivers that depend on the previous
      behaviour on powerpc, which was that the mmiowb wasn't actually required.
      Therefore we have a per-cpu flag that is set by writeX, cleared by
      __raw_spin_lock and mmiowb, and tested by __raw_spin_unlock.  If it is
      set, __raw_spin_unlock does a sync and clears it.
      
      This changes both 32-bit and 64-bit readX/writeX.  32-bit already has a
      sync in __raw_spin_unlock (since lwsync doesn't exist on 32-bit), and thus
      doesn't need the per-cpu flag.
      
      Tested on G5 (PPC970) and POWER5.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f007cacf
  20. 08 8月, 2006 1 次提交
  21. 15 6月, 2006 1 次提交
    • P
      powerpc: Use 64k pages without needing cache-inhibited large pages · bf72aeba
      Paul Mackerras 提交于
      Some POWER5+ machines can do 64k hardware pages for normal memory but
      not for cache-inhibited pages.  This patch lets us use 64k hardware
      pages for most user processes on such machines (assuming the kernel
      has been configured with CONFIG_PPC_64K_PAGES=y).  User processes
      start out using 64k pages and get switched to 4k pages if they use any
      non-cacheable mappings.
      
      With this, we use 64k pages for the vmalloc region and 4k pages for
      the imalloc region.  If anything creates a non-cacheable mapping in
      the vmalloc region, the vmalloc region will get switched to 4k pages.
      I don't know of any driver other than the DRM that would do this,
      though, and these machines don't have AGP.
      
      When a region gets switched from 64k pages to 4k pages, we do not have
      to clear out all the 64k HPTEs from the hash table immediately.  We
      use the _PAGE_COMBO bit in the Linux PTE to indicate whether the page
      was hashed in as a 64k page or a set of 4k pages.  If hash_page is
      trying to insert a 4k page for a Linux PTE and it sees that it has
      already been inserted as a 64k page, it first invalidates the 64k HPTE
      before inserting the 4k HPTE.  The hash invalidation routines also use
      the _PAGE_COMBO bit, to determine whether to look for a 64k HPTE or a
      set of 4k HPTEs to remove.  With those two changes, we can tolerate a
      mix of 4k and 64k HPTEs in the hash table, and they will all get
      removed when the address space is torn down.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      bf72aeba
  22. 12 6月, 2006 1 次提交
  23. 26 4月, 2006 1 次提交
  24. 27 3月, 2006 1 次提交
    • A
      [PATCH] powerpc: Allow non zero boot cpuids · 4df20460
      Anton Blanchard 提交于
      We currently have a hack to flip the boot cpu and its secondary thread
      to logical cpuid 0 and 1. This means the logical - physical mapping will
      differ depending on which cpu is boot cpu. This is most apparent on
      kexec, where we might kexec on any cpu and therefore change the mapping
      from boot to boot.
      
      The patch below does a first pass early on to work out the logical cpuid
      of the boot thread. We then fix up some paca structures to match.
      
      Ive also removed the boot_cpuid_phys variable for ppc64, to be
      consistent we use get_hard_smp_processor_id(boot_cpuid) everywhere.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4df20460
  25. 24 2月, 2006 1 次提交
    • P
      powerpc: Implement accurate task and CPU time accounting · c6622f63
      Paul Mackerras 提交于
      This implements accurate task and cpu time accounting for 64-bit
      powerpc kernels.  Instead of accounting a whole jiffy of time to a
      task on a timer interrupt because that task happened to be running at
      the time, we now account time in units of timebase ticks according to
      the actual time spent by the task in user mode and kernel mode.  We
      also count the time spent processing hardware and software interrupts
      accurately.  This is conditional on CONFIG_VIRT_CPU_ACCOUNTING.  If
      that is not set, we do tick-based approximate accounting as before.
      
      To get this accurate information, we read either the PURR (processor
      utilization of resources register) on POWER5 machines, or the timebase
      on other machines on
      
      * each entry to the kernel from usermode
      * each exit to usermode
      * transitions between process context, hard irq context and soft irq
        context in kernel mode
      * context switches.
      
      On POWER5 systems with shared-processor logical partitioning we also
      read both the PURR and the timebase at each timer interrupt and
      context switch in order to determine how much time has been taken by
      the hypervisor to run other partitions ("steal" time).  Unfortunately,
      since we need values of the PURR on both threads at the same time to
      accurately calculate the steal time, and since we can only calculate
      steal time on a per-core basis, the apportioning of the steal time
      between idle time (time which we ceded to the hypervisor in the idle
      loop) and actual stolen time is somewhat approximate at the moment.
      
      This is all based quite heavily on what s390 does, and it uses the
      generic interfaces that were added by the s390 developers,
      i.e. account_system_time(), account_user_time(), etc.
      
      This patch doesn't add any new interfaces between the kernel and
      userspace, and doesn't change the units in which time is reported to
      userspace by things such as /proc/stat, /proc/<pid>/stat, getrusage(),
      times(), etc.  Internally the various task and cpu times are stored in
      timebase units, but they are converted to USER_HZ units (1/100th of a
      second) when reported to userspace.  Some precision is therefore lost
      but there should not be any accumulating error, since the internal
      accumulation is at full precision.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c6622f63
  26. 10 2月, 2006 1 次提交
  27. 13 1月, 2006 1 次提交
    • D
      [PATCH] powerpc: Remove lppaca structure from the PACA · 3356bb9f
      David Gibson 提交于
      At present the lppaca - the structure shared with the iSeries
      hypervisor and phyp - is contained within the PACA, our own low-level
      per-cpu structure.  This doesn't have to be so, the patch below
      removes it, making a separate array of lppaca structures.
      
      This saves approximately 500*NR_CPUS bytes of image size and kernel
      memory, because we don't need aligning gap between the Linux and
      hypervisor portions of every PACA.  On the other hand it means an
      extra level of dereference in many accesses to the lppaca.
      
      The patch also gets rid of several places where we assign the paca
      address to a local variable for no particular reason.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3356bb9f
  28. 11 1月, 2006 1 次提交
    • A
      [PATCH] powerpc/64: per cpu data optimisations · 7a0268fa
      Anton Blanchard 提交于
      The current ppc64 per cpu data implementation is quite slow. eg:
      
              lhz 11,18(13)           /* smp_processor_id() */
              ld 9,.LC63-.LCTOC1(30)  /* per_cpu__variable_name */
              ld 8,.LC61-.LCTOC1(30)  /* __per_cpu_offset */
              sldi 11,11,3            /* form index into __per_cpu_offset */
              mr 10,9
              ldx 9,11,8              /* __per_cpu_offset[smp_processor_id()] */
              ldx 0,10,9              /* load per cpu data */
      
      5 loads for something that is supposed to be fast, pretty awful. One
      reason for the large number of loads is that we have to synthesize 2
      64bit constants (per_cpu__variable_name and __per_cpu_offset).
      
      By putting __per_cpu_offset into the paca we can avoid the 2 loads
      associated with it:
      
              ld 11,56(13)            /* paca->data_offset */
              ld 9,.LC59-.LCTOC1(30)  /* per_cpu__variable_name */
              ldx 0,9,11              /* load per cpu data
      
      Longer term we can should be able to do even better than 3 loads.
      If per_cpu__variable_name wasnt a 64bit constant and paca->data_offset
      was in a register we could cut it down to one load. A suggestion from
      Rusty is to use gcc's __thread extension here. In order to do this we
      would need to free up r13 (the __thread register and where the paca
      currently is). So far Ive had a few unsuccessful attempts at doing that :)
      
      The patch also allocates per cpu memory node local on NUMA machines.
      This patch from Rusty has been sitting in my queue _forever_ but stalled
      when I hit the compiler bug. Sorry about that.
      
      Finally I also only allocate per cpu data for possible cpus, which comes
      straight out of the x86-64 port. On a pseries kernel (with NR_CPUS == 128)
      and 4 possible cpus we see some nice gains:
      
                   total       used       free     shared    buffers cached
      Mem:       4012228     212860    3799368          0          0 162424
      
                   total       used       free     shared    buffers cached
      Mem:       4016200     212984    3803216          0          0 162424
      
      A saving of 3.75MB. Quite nice for smaller machines. Note: we now have
      to be careful of per cpu users that touch data for !possible cpus.
      
      At this stage it might be worth making the NUMA and possible cpu
      optimisations generic, but per cpu init is done so early we have to be
      careful that all architectures have their possible map setup correctly.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7a0268fa
  29. 09 1月, 2006 3 次提交
    • A
      [PATCH] powerpc: sanitize header files for user space includes · 88ced031
      Arnd Bergmann 提交于
      include/asm-ppc/ had #ifdef __KERNEL__ in all header files that
      are not meant for use by user space, include/asm-powerpc does
      not have this yet.
      
      This patch gets us a lot closer there. There are a few cases
      where I was not sure, so I left them out. I have verified
      that no CONFIG_* symbols are used outside of __KERNEL__
      any more and that there are no obvious compile errors when
      including any of the headers in user space libraries.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      88ced031
    • D
      [PATCH] powerpc: Remove some unneeded fields from the paca · 404849bb
      David Gibson 提交于
      This patch removes several unnecessary fields from the paca:
      
      - next_jiffy_update_tb was simply unused.  Remove trivially.
      
      - The exdsi exception save area was not used.  There were plans to use
        it, but they never seem to have gone anywhere.  If they ever do, we
        can put it back.  Remove from the paca, and from asm-offsets.c
      
      - The default_decr field was used from asm, but was only ever assigned
        the value of tb_ticks_per_jiffy.  Just access tb_ticks_per_jiffy from
        asm directly instead.
      
      Built and booted on POWER5 LPAR and iSeries RS64.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      404849bb
    • D
      [PATCH] powerpc: Remove ItLpRegSave area from the paca · 1888e7b5
      David Gibson 提交于
      On iSeries, the paca contains, amongst other things an ItLpRegSave
      structure used by the hypervisor to save registers.  The hypervisor
      locates this area through a pointer at the beginning of the paca, so
      the structure itself can be located elsewhere.  This patch moves the
      reg_save area out into its own array.  This reduces the amount of
      iSeries specific gunk which is visible to general powerpc code via
      paca.h
      
      Built and booted on POWER5 LPAR and iSeries RS64.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      1888e7b5
  30. 10 11月, 2005 1 次提交
    • D
      [PATCH] powerpc: Move various ppc64 files with no ppc32 equivalent to powerpc · 8882a4da
      David Gibson 提交于
      This patch moves a bunch of files from arch/ppc64 and
      include/asm-ppc64 which have no equivalents in ppc32 code into
      arch/powerpc and include/asm-powerpc.  The file affected are:
      	abs_addr.h
      	compat.h
      	lppaca.h
      	paca.h
      	tce.h
      	cpu_setup_power4.S
      	ioctl32.c
      	firmware.c
      	pacaData.c
      
      The only changes apart from the move and corresponding Makefile
      changes are:
      	- #ifndef/#define in includes updated to _ASM_POWERPC_ form
      	- trailing whitespace removed
      	- comments giving full paths removed
      	- pacaData.c renamed paca.c to remove studlyCaps
      	- Misplaced { moved in lppaca.h
      
      Built and booted on POWER5 LPAR (ARCH=powerpc and ARCH=ppc64), built
      for 32-bit powermac (ARCH=powerpc).
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      8882a4da
  31. 07 11月, 2005 1 次提交
    • B
      [PATCH] ppc64: support 64k pages · 3c726f8d
      Benjamin Herrenschmidt 提交于
      Adds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel
      base page size to 64K.  The resulting kernel still boots on any
      hardware.  On current machines with 4K pages support only, the kernel
      will maintain 16 "subpages" for each 64K page transparently.
      
      Note that while real 64K capable HW has been tested, the current patch
      will not enable it yet as such hardware is not released yet, and I'm
      still verifying with the firmware architects the proper to get the
      information from the newer hypervisors.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3c726f8d
  32. 02 11月, 2005 1 次提交
  33. 30 6月, 2005 2 次提交
  34. 22 6月, 2005 1 次提交
  35. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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