aboutsummaryrefslogtreecommitdiff
path: root/sys/cddl/dev/dtrace/amd64/dtrace_subr.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC r236566 (by zml):Mark Johnston2014-05-111-1/+1
| | | | | | | | | | | Fix DTrace TSC skew calculation: The skew calculation here is exactly backwards. We were able to repro it on a multi-package ESX server running a FreeBSD VM, where the TSCs can be pretty evil. Notes: svn path=/stable/9/; revision=265882
* MFC r257417: Remove references to an unused fasttrap probe hookAndriy Gapon2014-02-171-8/+0
| | | | Notes: svn path=/stable/9/; revision=262043
* MFC: 236567George V. Neville-Neil2013-06-121-7/+12
| | | | | | | | | | Integrate a fix for a very odd signal delivery problem found by Bryan Cantril and others in the Solaris/Illumos version of DTrace. Obtained from: https://www.illumos.org/issues/789 Notes: svn path=/stable/9/; revision=251666
* MFC: 238537,238552George V. Neville-Neil2012-12-101-2/+7
| | | | | | | | | | Add support for walltimestamp in DTrace. Submitted by: Fabian Keil Includes correction by: avg Notes: svn path=/stable/9/; revision=244093
* Remove pc_cpumask usage from dtrace MD supportAttilio Rao2011-06-281-2/+2
| | | | Notes: svn path=/projects/largeSMP/; revision=223641
* MFCAttilio Rao2011-05-101-21/+1
|\ | | | | | | Notes: svn path=/projects/largeSMP/; revision=221742
| * dtrace: remove unused codeAndriy Gapon2011-05-101-21/+1
| | | | | | | | | | | | | | | | | | Which is also useless, IMO. MFC after: 5 days Notes: svn path=/head/; revision=221740
* | Commit the support for removing cpumask_t and replacing it directly withAttilio Rao2011-05-051-4/+5
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpus > 32 (as it is today). Right now, cpumask_t is an int, 32 bits on all our supported architecture. cpumask_t on the other side is implemented as an array of longs, and easilly extendible by definition. The architectures touched by this commit are the following: - amd64 - i386 - pc98 - arm - ia64 - XEN while the others are still missing. Userland is believed to be fully converted with the changes contained here. Some technical notes: - This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future) - per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown - size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example). - Support for other architectures is going to be added soon - Only MAXCPU for amd64 is bumped now The patch has been tested by sbruno and Nicholas Esborn on opteron 4 x 12 pack CPUs. More testing on big SMP is expected to came soon. pluknet tested the patch with his 8-ways on both amd64 and i386. Tested by: pluknet, sbruno, gianni, Nicholas Esborn Reviewed by: jeff, jhb, sbruno Notes: svn path=/projects/largeSMP/; revision=221499
* Use atomic load & store for TSC frequency. It may be overkill for amd64 butJung-uk Kim2011-04-071-1/+1
| | | | | | | | | | | | safer for i386 because it can be easily over 4 GHz now. More worse, it can be easily changed by user with 'machdep.tsc_freq' tunable (directly) or cpufreq(4) (indirectly). Note it is intentionally not used in performance critical paths to avoid performance regression (but we should, in theory). Alternatively, we may add "virtual TSC" with lower frequency if maximum frequency overflows 32 bits (and ignore possible incoherency as we do now). Notes: svn path=/head/; revision=220433
* Fix typos - remove duplicate "the".Rebecca Cran2011-02-211-1/+1
| | | | | | | | | PR: bin/154928 Submitted by: Eitan Adler <lists at eitanadler.com> MFC after: 3 days Notes: svn path=/head/; revision=218909
* dtrace_xcall: no need for special handling of curcpuAndriy Gapon2010-12-071-16/+3
| | | | | | | | | | smp_rendezvous_cpus alreadt does the right thing in a very similar fashion, so the code was kind of duplicating that. MFC after: 3 weeks Notes: svn path=/head/; revision=216251
* dtrace_gethrtime_init: pin to master while examining other CPUsAndriy Gapon2010-12-071-4/+5
| | | | | | | | | | Also use pc_cpumask to be future-friendly. Reviewed by: jhb MFC after: 2 weeks Notes: svn path=/head/; revision=216250
* Update several places that iterate over CPUs to use CPU_FOREACH().John Baldwin2010-06-111-4/+1
| | | | Notes: svn path=/head/; revision=209059
* dtrace_gethrtime: improve scaling of TSC ticks to nanosecondsAndriy Gapon2009-07-151-3/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently dtrace_gethrtime uses formula similar to the following for converting TSC ticks to nanoseconds: rdtsc() * 10^9 / tsc_freq The dividend overflows 64-bit type and wraps-around every 2^64/10^9 = 18446744073 ticks which is just a few seconds on modern machines. Now we instead use precalculated scaling factor of 10^9*2^N/tsc_freq < 2^32 and perform TSC value multiplication separately for each 32-bit half. This allows to avoid overflow of the dividend described above. The idea is taken from OpenSolaris. This has an added feature of always scaling TSC with invariant value regardless of TSC frequency changes. Thus the timestamps will not be accurate if TSC actually changes, but they are always proportional to TSC ticks and thus monotonic. This should be much better than current formula which produces wildly different non-monotonic results on when tsc_freq changes. Also drop write-only 'cp' variable from amd64 dtrace_gethrtime_init() to make it identical to the i386 twin. PR: kern/127441 Tested by: Thomas Backman <serenity@exscape.org> Reviewed by: jhb Discussed with: current@, bde, gnn Silence from: jb Approved by: re (gnn) MFC after: 1 week Notes: svn path=/head/; revision=195710
* dtrace/amd64: fix virtual address checksAndriy Gapon2009-06-241-1/+0
| | | | | | | | | | | | | | | | | | On amd64 KERNBASE/kernbase does not mean start of kernel memory. This should fix a KASSERT panic in dtrace_copycheck when copyin*() is used in D program. Also make checks for user memory a bit stricter. Reported by: Thomas Backman <serenity@exscape.org> Submitted by: wxs (kaddr part) Tested by: Thomas Backman (prototype), wxs Reviewed by: alc (concept), jhb, current@ Aprroved by: jb (concept) MFC after: 2 weeks PR: kern/134408 Notes: svn path=/head/; revision=194850
* Custom DTrace kernel module files plus FreeBSD-specific DTrace providers.John Birrell2008-05-231-0/+507
Notes: svn path=/head/; revision=179237