summaryrefslogtreecommitdiffstats
path: root/mm/vmscan.c
diff options
context:
space:
mode:
authorHelge Deller <deller@gmx.de>2016-04-20 21:34:15 +0200
committerHelge Deller <deller@gmx.de>2016-05-22 21:39:25 +0200
commit54b668009076caddbede8fde513ca2c982590bfe (patch)
tree873f576cebe662cdb3c8a6626ba6be193a0a6ef4 /mm/vmscan.c
parent64e2a42bca12e408f0258c56adcf3595bcd116e7 (diff)
downloadlinux-54b668009076caddbede8fde513ca2c982590bfe.tar.bz2
parisc: Add native high-resolution sched_clock() implementation
Add a native implementation for the sched_clock() function which utilizes the processor-internal cycle counter (Control Register 16) as high-resolution time source. With this patch we now get much more fine-grained resolutions in various in-kernel time measurements (e.g. when viewing the function tracing logs), and probably a more accurate scheduling on SMP systems. There are a few specific implementation details in this patch: 1. On a 32bit kernel we emulate the higher 32bits of the required 64-bit resolution of sched_clock() by increasing a per-cpu counter at every wrap-around of the 32bit cycle counter. 2. In a SMP system, the cycle counters of the various CPUs are not syncronized (similiar to the TSC in a x86_64 system). To cope with this we define HAVE_UNSTABLE_SCHED_CLOCK and let the upper layers do the adjustment work. 3. Since we need HAVE_UNSTABLE_SCHED_CLOCK, we need to provide a cmpxchg64() function even on a 32-bit kernel. 4. A 64-bit SMP kernel which is started on a UP system will mark the sched_clock() implementation as "stable", which means that we don't expect any jumps in the returned counter. This is true because we then run only on one CPU. Signed-off-by: Helge Deller <deller@gmx.de>
Diffstat (limited to 'mm/vmscan.c')
0 files changed, 0 insertions, 0 deletions