1. 14 12月, 2009 1 次提交
  2. 11 12月, 2009 1 次提交
  3. 09 12月, 2009 3 次提交
  4. 04 12月, 2009 2 次提交
    • M
      sh: Drop associative writes for SH-4 cache flushes. · a781d1e5
      Matt Fleming 提交于
      When flushing/invalidating the icache/dcache via the memory-mapped IC/OC
      address arrays, the associative bit should only be used in conjunction with
      virtual addresses. However, we currently flush cache lines based on physical
      address, so stop using the associative bit.
      
      It is a better strategy to use non-associative writes (and physical tags) for
      flushing the caches anyway, because flushing by virtual address (as with the
      A-bit set) requires a valid TLB entry for that virtual address. If one does not
      exist in the TLB no exception is generated and the flush is silently ignored.
      
      This is also future-proofing for SH-4A parts which are gradually phasing out
      associative writes to the cache array due to the aforementioned case of certain
      flushes silently turning in to nops.
      Signed-off-by: NMatt Fleming <matt@console-pimps.org>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      a781d1e5
    • P
      sh: Partial revert of copy/clear_user_highpage() optimizations. · 7e01c949
      Paul Mundt 提交于
      These still require more testing, so revert them for now. We keep the
      off-by-1 in the fixmap colouring and drop the rest.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      7e01c949
  5. 24 11月, 2009 1 次提交
    • S
      sh: Improve performance of SH4 versions of copy/clear_user_highpage · 39ac11c1
      Stuart Menefy 提交于
      The previous implementation of clear_user_highpage and copy_user_highpage
      checked to see if there was a D-cache aliasing issue between the user
      and kernel mappings of a page, but if there was they always did a
      flush with writeback on the dirtied kernel alias.
      
      However as we now have the ability to map a page into kernel space
      with the same cache colour as the user mapping, there is no need to
      write back this data.
      
      Currently we also invalidate the kernel alias as a precaution, however
      I'm not sure if this is actually required.
      
      Also correct the definition of FIX_CMAP_END so that the mappings created
      by kmap_coherent() are actually at the correct colour.
      Signed-off-by: NStuart Menefy <stuart.menefy@st.com>
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      39ac11c1
  6. 12 11月, 2009 1 次提交
  7. 11 11月, 2009 1 次提交
  8. 09 11月, 2009 1 次提交
  9. 04 11月, 2009 1 次提交
  10. 30 10月, 2009 1 次提交
  11. 27 10月, 2009 3 次提交
  12. 26 10月, 2009 1 次提交
  13. 20 10月, 2009 1 次提交
  14. 16 10月, 2009 3 次提交
  15. 13 10月, 2009 1 次提交
  16. 10 10月, 2009 9 次提交
  17. 09 10月, 2009 4 次提交
  18. 23 9月, 2009 3 次提交
  19. 22 9月, 2009 1 次提交
  20. 21 9月, 2009 1 次提交
    • 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