Re: PROBLEM: Performance drop

] ACPI: make evaluation of thermal trip points before temperature or vice versa dependant on new temp_b4_trip module parameter to support older AMD x86_64s Kernel x Jason Vas Dias Jul 9 (5 days ago) Reply to Rusty, linux-kernel, Andreas, Matthew, Len, Comrade Thanks

[PATCH: 1/1] ACPI: make evaluation of thermal trip points before temperature or vice versa dependant on new temp_b4_trip module parameter to support older AMD x86_64s

This patch adds a new acpi.thermal.temp_b4_trip = 1 settting, which causes the temperature to be set before evaluation of thermal trip points (the old default) . This mode should be selected automatically by DMI match if the system identifies as HPCompaq 6715b . Please consider applying a

Re: PROBLEM: Performance drop

-old hardware I guess, but still - please can you restore correct Linux cpufreq thermal operation on old-style AMD k8 CPUs ? They do seem to depend on the temperature being set BEFORE 1st entry . Thanks Regards, Jason Vas Dias (a Software Engineer) jason.vas.d...@gmail.com On Wed, May 30, 2012

Re: PROBLEM: Performance drop

Sorry, of course the commit I backed out was : 9bcb8118965ab4631a65ee0726e6518f75cda6c5. On Sat, Jul 7, 2012 at9bcb8118965ab4631a65ee0726e6518f75cda6c5. 3:40 PM, Jason Vas Dias jason.vas.d...@gmail.com wrote: I can confirm that the AMD Turion X2 2.2Ghz HP Compaq 6715b business x86_64 k8 dual

[PATCH: 1/1] ACPI: make evaluation of thermal trip points before temperature or vice versa dependant on new temp_b4_trip module parameter to support older AMD x86_64s

This patch adds a new acpi.thermal.temp_b4_trip = 1 settting, which causes the temperature to be set before evaluation of thermal trip points (the old default) ; this mode should be selected automatically by DMI match if the system identifies as HP Compaq 6715b . Please consider applying a patch

Re: [PATCH: 1/1] ACPI: make evaluation of thermal trip points before temperature or vice versa dependant on new temp_b4_trip module parameter to support older AMD x86_64s

19:50:54 +0100, Jason Vas Dias jason.vas.d...@gmail.com wrote: This patch adds a new acpi.thermal.temp_b4_trip = 1 settting, which causes the temperature to be set before evaluation of thermal trip points (the old default) ; this mode should be selected automatically by DMI match

HP6715b laptop's wireless radio on LED went off after 1st boot of 3.9.6 from 3.4.4 - please help / any ideas ?

After building and installing 3.9.6 kernel modules on my 2.2ghz HP6715b x86-64 Turion dual core laptop , which has always run Linux with no b43 wireless problems since 2007, now has no access to its onboard broadcom 4311 wireless radio . I had always used the b43 driver with the correct firmware

how to build kernel-firmware and kernel-doc RPMs from Red Hat EL6 kernel.spec files ?

replies, best Regards, Jason Vas Dias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

mount BTRFS filesystems created with 3.8+ under 2.6.32 kernels ?

snapshot/mnt/btr /mnt/btr/root-w-0 Now I can mount /dev/sda9 under any 3.8+ kernel, but not under 2.6.32 . Thanks in advance for any replies, Best Regards, Jason Vas Dias -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: mount BTRFS filesystems created with 3.8+ under 2.6.32 kernels ?

Of course the solution was to have created the filesystem in the first place with 'mkfs.btrfs -O ^extref' . Found this after some more googling ... Shouldn't this be the default ? Regards, Jason On 9/22/14, Jason Vas Dias jason.vas.d...@gmail.com wrote: Good day - I wonder if there is a GIT

how to build 2.6.x based kernel with perf ?

Good day - I am trying to build the latest RHEL kernel from the source RPM, but this fails because the perf component cannot build . The build gets as far as building the modules and debug flavour of the kernel, but fails for the 'perf' target with : + make -j4 -C tools/perf -s V=1 prefix=/usr

Re: how to build 2.6.x based kernel with perf ?

Here's a patch that fixes the issue for me . Also attached to Red Hat bugzilla : https://bugzilla.redhat.com/show_bug.cgi?id=1173649 On 12/12/14, Jason Vas Dias jason.vas.d...@gmail.com wrote: Good day - I am trying to build the latest RHEL kernel from the source RPM, but this fails because

how to unmount an rbind mount ?

Good day - Please could anyone advise - Once one has mounted an alias mount with the 'rbind' option, so that mounts underneath it are also mounted under the new path, how can one unmount that filesystem safely without un-mounting the original mountpoints ? For example, I do this for chroots :

4.5.x drm/i915/ + drm/drm_irq + drm/radeon & ACPI problems doing vga_switcheroo switching & getting EDID modes for laptop hybrid graphics with Intel IGC & Radeon Neptune 8970M

I have not so far been able to get my Radeon 8970M discrete graphics card with GPU to go into graphics mode under Linux 4.4.0+ ( tried 4.4.0, 4.5.0, 4.5.1, ...) on my Clevo KAPOK laptop x86_64 LFS system , which has : CPU : Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz RAM: 16GB ; Disk: 1TB SATA +

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

On 22/02/2017, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: > RE: >>> 4.10 has new code which utilizes the TSC_ADJUST MSR. > > I just built an unpatched linux v4.10 with tglx's TSC improvements - > much else improved in this kernel (like iwlwifi) - thanks! >

[PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

I originally reported this issue on bugzilla.kernel.org : bug # 194609 : https://bugzilla.kernel.org/show_bug.cgi?id=194609 , but it was not posted to the list . My CPU reports 'model name' as "Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz" , has 4 physical & 8 hyperthreading cores with a frequency

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

ns1: 0.01367 ts3 - ts2: 23 ns1: 0.01425 ts3 - ts2: 23 ns1: 0.01357 ts3 - ts2: 22 ns1: 0.01487 ts3 - ts2: 25 ns1: 0.01377 t1 - t0: 145753 - ns2: 0.000150781 (complete source of test program ttsc1 attached in ttsc.tar $ tar -xpf ttsc.tar $ cd ttsc $ make ). On 22/02/2017, Jason Vas

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

y ? On 22/02/2017, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: > Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is > read or written . It is probably because it genuinuely does not > support any cpuid > 13 , > or the modern TSC_ADJUST interface . Thi

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

? I am searching for all places where a '[.>]mult.*=' occurs, but this returns rather alot of matches. Please could a future version of linux at least export the 'mult' and 'shift' values for the current clocksource ! Regards, Jason On 22/02/2017, Jason Vas Dias <jason.vas.d...@gmai

[PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

Patch to make tsc.c set X86_FEATURE_ART and setup the TSC_ADJUST MSR correctly on my "i7-4910MQ" CPU, which reports ( boot_cpu_data.cpuid_level==0x13 && boot_cpu_data.extended_cpuid_level==0x8008 ), so the code didn't think it supported CPUID:15h, but it does . Patch: diff --git

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

)_ia64_tsc_mult))>>_ia64_tsc_shift); return( (((ns / NSEC_PER_SEC)&0xUL) << 32) | ((ns % NSEC_PER_SEC)&0x3fffUL) ); /* Yes, we are purposefully ignoring durations of more than 4.2 billion seconds here! */ } I think Linux should export the 'tsc_khz', 'mult'

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

worth, and how I'd like to eventually get things working on my system. All the best, Regards, Jason On 22/02/2017, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: > On 22/02/2017, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: >> RE: >>>> 4.10 has new c

Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

ft' values via sysfs. Regards, Jason. On 21/02/2017, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: > Thank You for enlightening me - > > I was just having a hard time believing that Intel would ship a chip > that features a monotonic, fixed frequency timestamp counter > w

Re: please, where has xconfig KConf option documentation gone with linux 4.8's Qt5 / Qt4 xconfig ?

; option ? why don't I see one ? Maybe the Options menu might be a good place to put an "Expand Option Documentation Pane" option ? Thanks anyway for the info. Regards, Jason On 11/10/2016, Randy Dunlap <rdun...@infradead.org> wrote: > [changed linux-config to linux-kbui

please, where has xconfig KConf option documentation gone with linux 4.8's Qt5 / Qt4 xconfig ?

Hi - I've been doing 'make xconfig' to configure the kernel for many years now, and always there used to be some option documentation pane populated with summary documentation for the specific option selected . But now, when built for Qt 5.7.0, (also tried Qt 4.8 and GTK) there is no option

Re: Differences between builtins and modules

Sorry I didn't see this mail until now - RE: Randy Dunlap wrote: > Would someone please answer/reply to this (related) kernel bugzilla entry: > https://bugzilla.kernel.org/show_bug.cgi?id=118661 Yes, I raised this bug because I think modinfo should return 0 exit status if

Re: perf Intel x86_64 : BUG: BRANCH_INSTRUCTIONS / BRANCH_MISSES cannot be combined with CACHE_REFERENCES / CACHE_MISSES .

On 13/02/2018, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: > Good day - > > I'd much appreciate some advice as to why, on my Intel x86_64 > ( DisplayFamily_DisplayModel : 06_3CH ), running either Linux 4.12.10, > or Linux 3.10.0, any

perf Intel x86_64 : BUG: BRANCH_INSTRUCTIONS / BRANCH_MISSES cannot be combined with CACHE_REFERENCES / CACHE_MISSES .

Good day - I'd much appreciate some advice as to why, on my Intel x86_64 ( DisplayFamily_DisplayModel : 06_3CH ), running either Linux 4.12.10, or Linux 3.10.0, any attempt to count all of : PERF_COUNT_HW_BRANCH_INSTRUCTIONS (or raw config 0xC4) , and

[PATCH v4.15.7 1/1] x86/vdso: handle clock_gettime(CLOCK_MONOTONIC_RAW, ) in VDSO

Handling clock_gettime( CLOCK_MONOTONIC_RAW, ) by calling vdso_fallback_gettime(), ie. syscall, is too slow - latencies of 300-700ns are common on Haswell (06:3C) CPUs . This patch against the 4.15.7 stable branch makes the VDSO handle clock_gettime(CLOCK_GETTIME_RAW, ) by issuing rdtscp in

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ion/coding-style.rst and calling 'indent-region' and 'tabify' (whitespace only changes) - SORRY ! Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc4/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc4 linux-4.16-rc4/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc4

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ion/coding-style.rst and calling 'indent-region' and 'tabify' (whitespace only changes) - SORRY ! (and even after that, somehow 2 '\t\n's got left in vgtod.h - now removed - sorry again!) . Best Regards, Jason Vas Dias . PATCH: --- diff -up linux-4.16-rc4/arch/x86/entry/vdso/vcloc

Re: [PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Thanks Thomas - On 11/03/2018, Thomas Gleixner <t...@linutronix.de> wrote: > On Sun, 11 Mar 2018, Jason Vas Dias wrote: > > This looks better now. Though running that patch through checkpatch.pl > results in: > > total: 28 errors, 20 warnings, 139 lines check

Re: [PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Good day - On 12/03/2018, Ingo Molnar <mi...@kernel.org> wrote: > > * Thomas Gleixner <t...@linutronix.de> wrote: > >> On Mon, 12 Mar 2018, Jason Vas Dias wrote: >> >> checkpatch.pl still reports: >> >>total: 15 errors, 3 warnings, 165 lin

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

it . This patch affects only files: arch/x86/include/asm/msr.h arch/x86/include/asm/vgtod.h arch/x86/entry/vdso/vclock_gettime.c arch/x86/entry/vsyscall/vsyscall_gtod.c This is the second patch in the series, which adds use of rdtscp . Best Regards, Jason Vas Dias

[PATCH v4.16-rc4 1/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ction . The patch passes the checkpatch.pl script . Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5

[PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

he second uses new rstscp() function which avoids use of an explicit barrier. Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc5.1/arch/x86/entry/vdso/v

Re: [PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

The split patches with no checkpatch.pl failures are attached and were just sent in separate emails to the mailing list . Sorry it took a few tries to get right . This will be my last send today - I'm off to use it at work. Thanks & all the best, Jason

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

used by user-space code to implement sub-nanosecond precision clocks . This second patch is entirely optional but I think greatly expands the scope of user-space TSC readers . Oops, previous version of this second patch mistakenly copied the changed part of vclock_gettime.c. Best Reg

[PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

rs . Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 2018-03-12 00:25:09.0 + +++ linux-4.16-rc5

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

used by user-space code to implement sub-nanosecond precision clocks . This second patch is entirely optional but I think greatly expands the scope of user-space TSC readers . Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

on of this patch (#2), the comments in the new vdso_tsc_calibration were wrong, for an earlier version - sorry about that. Best Regards, Jason Vas Dias . PATCH 2/2: --- diff -up linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5-p1 linux-4.16-rc5/arch/x86/entry/vdso/vclock

[PATCH v4.16-rc5 2/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index fbc7371..2c46675 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -184,10 +184,9 @@ notrace static u64 vread_tsc(void) notrace static u64

[PATCH v4.16-rc5 1/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index f19856d..fbc7371 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -182,6 +182,18 @@ notrace static u64 vread_tsc(void) return last; } +notrace

[PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ttime(CLOCK_MONOTONIC_RAW) calls have @ half the latency of clock_gettime(CLOCK_MONOTONIC) calls. I think something like Patch #3 is necessary to export TSC calibration data to user-space TSC readers. Best Regards, Jason Vas Dias

[PATCH v4.16-rc5 3/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index 2c46675..772988c 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -21,6 +21,7 @@ #include #include #include +#include #define gtod

[PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

o include patches #2 and #3, but I think something like Patch #1 really needs to get into a future Linux release, as an unecessary latency of 200-1000ns for a timer that can tick 3 times per nanosecond is unacceptable. Patches for kernels 3.10.0-21 and 4.9.65-rt23 (ARM) are attached to bug

[PATCH v4.16-rc5 2/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index fbc7371..2c46675 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -184,10 +184,9 @@ notrace static u64 vread_tsc(void) notrace static u64

[PATCH v4.16-rc5 1/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index f19856d..fbc7371 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -182,6 +182,18 @@ notrace static u64 vread_tsc(void) return last; } +notrace

[PATCH v4.16-rc5 3/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index 03f3904..61d9633 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -21,12 +21,15 @@ #include #include #include +#include #define gtod

Re: [PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Hi Thomas - RE: On 15/03/2018, Thomas Gleixner wrote: > Jason, > > On Thu, 15 Mar 2018, jason.vas.d...@gmail.com wrote: > >> Resent to address reviewer comments. > > I was being patient so far and tried to guide you through the patch > submission process, but unfortunately

[PATCH v4.16-rc5 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

) are attached to bug #198161, as is the test program, timer_latency.c, to demonstrate the problem. Before the patch a latency of 200-1000ns was measured for clock_gettime(CLOCK_MONOTONIC_RAW,) calls - after the patch, the same call on the same machine has a latency of @ 20ns. Thanks & Best Regards, Jason Vas Dias

[PATCH v4.16-rc5 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index f19856d..8b9b9cf 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -182,27 +182,49 @@ notrace static u64 vread_tsc(void) return last; } -notrace

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

, current HEAD of : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . The patch affects only files: arch/x86/include/asm/vgtod.h arch/x86/entry/vdso/vclock_gettime.c arch/x86/entry/vsyscall/vsyscall_gtod.c Best Regards, Jason Vas Dias . --- diff -up

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

tree, current HEAD of : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . The patch affects only files: arch/x86/include/asm/vgtod.h arch/x86/entry/vdso/vclock_gettime.c arch/x86/entry/vsyscall/vsyscall_gtod.c Best Regards, Jason Vas Dias

Re: Fwd: [PATCH v4.15.7 1/1] on Intel, VDSO should handle CLOCK_MONOTONIC_RAW and export 'tsc_calibration' pointer

latencies down from > 300ns to < 20ns . Maybe I should post that also to kernel.org, or to ti.com ? I have a separate patch for the vdso_tsc_calibration export of the tsc_khz and calibration which no longer returns pointers into the VDSO - I can post this as a patch if you like. Thanks

Re: [PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Oops, please disregard 1st mail on $subject - I guess use of Quoted Printable is not a way of getting past the email line length. Patch I tried to send is attached as attachment - will resend inline using other method. Sorry, Regards, Jason vdso_monotonic_raw-v4.16-rc4.patch Description:

Re: Fwd: [PATCH v4.15.7 1/1] on Intel, VDSO should handle CLOCK_MONOTONIC_RAW and export 'tsc_calibration' pointer

On 08/03/2018, Thomas Gleixner <t...@linutronix.de> wrote: > On Tue, 6 Mar 2018, Jason Vas Dias wrote: >> I will prepare a new patch that meets submission + coding style guidelines >> and >> does not expose pointers within the vsyscall_gtod_data region to >> user-s

Fwd: [PATCH v4.15.7 1/1] on Intel, VDSO should handle CLOCK_MONOTONIC_RAW and export 'tsc_calibration' pointer

On 06/03/2018, Thomas Gleixner <t...@linutronix.de> wrote: > Jason, > > On Mon, 5 Mar 2018, Jason Vas Dias wrote: > > thanks for providing this. A few formal nits first. > > Please read Documentation/process/submitting-patches.rst > > Patches need a concise subjec

Re: [PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Thanks for the helpful comments, Peter - re: On 14/03/2018, Peter Zijlstra wrote: > >> Yes, I am sampling perf counters, > > You're not in fact sampling, you're just reading the counters. Correct, using Linux-ese terminology - but "sampling" in looser English. >> Reading

Re: [PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

On 12/03/2018, Peter Zijlstra <pet...@infradead.org> wrote: > On Mon, Mar 12, 2018 at 07:01:20AM +0000, Jason Vas Dias wrote: >> Sometimes, particularly when correlating elapsed time to performance >> counter values, > > So what actual problem are you tring to s

Re: [PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Good day - RE: On 15/03/2018, Thomas Gleixner <t...@linutronix.de> wrote: > On Thu, 15 Mar 2018, Jason Vas Dias wrote: >> On 15/03/2018, Thomas Gleixner <t...@linutronix.de> wrote: >> > On Thu, 15 Mar 2018, jason.vas.d...@gmail.com wrote: >> > >

re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

tency.c'). I do apologize for whitespace errors, unread emails and resends and confusion of previous emails - I now understand the process and standards much better and will attempt to adhere to them more closely in future. Thanks & Best Regards, Jason Vas Dias /* * Program to measure high-res

Re: [PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

fixed typo in timer_latency.c affecting only -r printout : $ gcc -DN_SAMPLES=1000 -o timer timer_latency.c CLOCK_MONOTONIC ( using rdtscp_ordered() ) : $ ./timer -m -r 10 sum: 67615 Total time: 0.67615S - Average Latency: 0.00067S N zero deltas: 0 N inconsistent deltas: 0 sum: 51858

Re: [PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

On 18/03/2018, Jason Vas Dias <jason.vas.d...@gmail.com> wrote: (should have CC'ed to list, sorry) > On 17/03/2018, Andi Kleen <a...@firstfloor.org> wrote: >> >> That's quite a mischaracterization of the issue. gcc works as intended, >> but the kernel did not

Re: [PATCH v4.16-rc6 (1)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

Note there is a bug raised by H.J. Liu : Bug 199129: Don't build vDSO with $(RETPOLINE_CFLAGS) -DRETPOLINE (https://bugzilla.kernel.org/show_bug.cgi?id=199129) If you agree it is a bug, then use both patches from post : '[PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle \

[PATCH v4.16-rc6 (1)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

call on the same machine has a latency of @ 20ns. Please consider applying something like this patch to a future Linux release. Thanks & Best Regards, Jason Vas Dias

[PATCH v4.16-rc6 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

This patch makes the vDSO handle clock_gettime(CLOCK_MONOTONIC_RAW,) calls in the same way it handles clock_gettime(CLOCK_MONOTONIC,) calls, reducing latency from @ 200-1000ns to @ 20ns. It has been resent and augmented to support compilation with

Re: [PATCH v4.16-rc6 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

Good day - I believe the last patch I sent, with $subject, addresses all concerns raised so far by reviewers, and complies with all kernel coding standards . Please, it would be most helpful if you could let me know whether the patch is now acceptable and will be applied at some stage or not -

[PATCH v4.16-rc6 (1)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

d by H.J. Liu, was not applied first - Sorry! Thanks & Best Regards, Jason Vas Dias

[PATCH v4.16-rc6 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

This patch implements clock_gettime(CLOCK_MONOTONIC_RAW,) calls entirely in the vDSO, without calling vdso_fallback_gettime() . It has been augmented to support compilation with or without -DRETPOLINE / $(RETPOLINE_CFLAGS) ; when compiled with -DRETPOLINE, not all functions

[PATCH v4.16-rc5 1/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

This patch makes the vDSO handle clock_gettime(CLOCK_MONOTONIC_RAW,) calls in the same way it handles clock_gettime(CLOCK_MONOTONIC,) calls, reducing latency from @ 200-1000ns to @ 20ns. diff --git a/arch/x86/entry/vdso/vclock_gettime.c

[PATCH v4.16-rc5 (2)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

AW,) calls - after the patch, the same call on the same machine has a latency of @ 20ns. Thanks & Best Regards, Jason Vas Dias

[PATCH v4.16-rc5 2/2] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

This patch allows compilation to succeed with compilers that support -DRETPOLINE - it was kindly contributed by H.J. Liu in GCC Bugzilla: 84908 : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84908 Apparently the GCC retpoline implementation has a limitation

[PATCH v4.15.7 1/1] on Intel, VDSO should handle CLOCK_MONOTONIC_RAW and export 'tsc_calibration' pointer

alues somehow . The documentation states for CLOCK_MONOTONIC_RAW that it is the same as CLOCK_MONOTONIC except it is NOT subject to NTP adjustments . This is very far from the case currently, without a patch like the one above. And the kernel should not restrict user-space programs to only being

HP6715b laptop's wireless radio on LED went off after 1st boot of 3.9.6 from 3.4.4 - please help / any ideas ?

After building and installing 3.9.6 kernel & modules on my 2.2ghz HP6715b x86-64 Turion dual core laptop , which has always run Linux with no b43 wireless problems since 2007, now has no access to its onboard broadcom 4311 wireless radio . I had always used the b43 driver with the correct

Re: [PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

On 12/03/2018, Peter Zijlstra wrote: > On Mon, Mar 12, 2018 at 07:01:20AM +0000, Jason Vas Dias wrote: >> Sometimes, particularly when correlating elapsed time to performance >> counter values, > > So what actual problem are you tring to solve here? Perf can already &

[PATCH v4.16-rc5 3/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index 2c46675..772988c 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -21,6 +21,7 @@ #include #include #include +#include #define gtod

[PATCH v4.16-rc5 2/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index fbc7371..2c46675 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -184,10 +184,9 @@ notrace static u64 vread_tsc(void) notrace static u64

[PATCH v4.16-rc5 (3)] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ttime(CLOCK_MONOTONIC_RAW) calls have @ half the latency of clock_gettime(CLOCK_MONOTONIC) calls. I think something like Patch #3 is necessary to export TSC calibration data to user-space TSC readers. Best Regards, Jason Vas Dias

[PATCH v4.16-rc5 1/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

diff --git a/arch/x86/entry/vdso/vclock_gettime.c b/arch/x86/entry/vdso/vclock_gettime.c index f19856d..fbc7371 100644 --- a/arch/x86/entry/vdso/vclock_gettime.c +++ b/arch/x86/entry/vdso/vclock_gettime.c @@ -182,6 +182,18 @@ notrace static u64 vread_tsc(void) return last; } +notrace

Re: [PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Thanks for the helpful comments, Peter - re: On 14/03/2018, Peter Zijlstra wrote: > >> Yes, I am sampling perf counters, > > You're not in fact sampling, you're just reading the counters. Correct, using Linux-ese terminology - but "sampling" in looser English. >> Reading performance counters

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

, current HEAD of : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . The patch affects only files: arch/x86/include/asm/vgtod.h arch/x86/entry/vdso/vclock_gettime.c arch/x86/entry/vsyscall/vsyscall_gtod.c Best Regards, Jason Vas Dias . --- diff -up

Re: [PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Oops, please disregard 1st mail on $subject - I guess use of Quoted Printable is not a way of getting past the email line length. Patch I tried to send is attached as attachment - will resend inline using other method. Sorry, Regards, Jason vdso_monotonic_raw-v4.16-rc4.patch Description:

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

tree, current HEAD of : git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . The patch affects only files: arch/x86/include/asm/vgtod.h arch/x86/entry/vdso/vclock_gettime.c arch/x86/entry/vsyscall/vsyscall_gtod.c Best Regards, Jason Vas Dias

Re: Fwd: [PATCH v4.15.7 1/1] on Intel, VDSO should handle CLOCK_MONOTONIC_RAW and export 'tsc_calibration' pointer

ns to < 20ns . Maybe I should post that also to kernel.org, or to ti.com ? I have a separate patch for the vdso_tsc_calibration export of the tsc_khz and calibration which no longer returns pointers into the VDSO - I can post this as a patch if you like. Thanks & Best Regards, Jason Va

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ion/coding-style.rst and calling 'indent-region' and 'tabify' (whitespace only changes) - SORRY ! Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc4/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc4 linux-4.16-rc4/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc4

[PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ion/coding-style.rst and calling 'indent-region' and 'tabify' (whitespace only changes) - SORRY ! (and even after that, somehow 2 '\t\n's got left in vgtod.h - now removed - sorry again!) . Best Regards, Jason Vas Dias . PATCH: --- diff -up linux-4.16-rc4/arch/x86/entry/vdso/vcloc

Re: [PATCH v4.16-rc4 1/1] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Thanks Thomas - On 11/03/2018, Thomas Gleixner wrote: > On Sun, 11 Mar 2018, Jason Vas Dias wrote: > > This looks better now. Though running that patch through checkpatch.pl > results in: > > total: 28 errors, 20 warnings, 139 lines checked > Hmm, I was unaware of that scri

[PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

rs . Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 2018-03-12 00:25:09.0 + +++ linux-4.16-rc5

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

used by user-space code to implement sub-nanosecond precision clocks . This second patch is entirely optional but I think greatly expands the scope of user-space TSC readers . Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

used by user-space code to implement sub-nanosecond precision clocks . This second patch is entirely optional but I think greatly expands the scope of user-space TSC readers . Oops, previous version of this second patch mistakenly copied the changed part of vclock_gettime.c. Best Reg

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

on of this patch (#2), the comments in the new vdso_tsc_calibration were wrong, for an earlier version - sorry about that. Best Regards, Jason Vas Dias . PATCH 2/2: --- diff -up linux-4.16-rc5/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5-p1 linux-4.16-rc5/arch/x86/entry/vdso/vclock

[PATCH v4.16-rc4 1/3] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

ction . The patch passes the checkpatch.pl script . Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5

Re: [PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

Good day - On 12/03/2018, Ingo Molnar wrote: > > * Thomas Gleixner wrote: > >> On Mon, 12 Mar 2018, Jason Vas Dias wrote: >> >> checkpatch.pl still reports: >> >>total: 15 errors, 3 warnings, 165 lines checked >> Sorry I didn't see you had r

[PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

he second uses new rstscp() function which avoids use of an explicit barrier. Best Regards, Jason Vas Dias . --- diff -up linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c.4.16-rc5 linux-4.16-rc5.1/arch/x86/entry/vdso/vclock_gettime.c --- linux-4.16-rc5.1/arch/x86/entry/vdso/v

[PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

it . This patch affects only files: arch/x86/include/asm/msr.h arch/x86/include/asm/vgtod.h arch/x86/entry/vdso/vclock_gettime.c arch/x86/entry/vsyscall/vsyscall_gtod.c This is the second patch in the series, which adds use of rdtscp . Best Regards, Jason Vas Dias

Re: [PATCH v4.16-rc4 1/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

The split patches with no checkpatch.pl failures are attached and were just sent in separate emails to the mailing list . Sorry it took a few tries to get right . This will be my last send today - I'm off to use it at work. Thanks & all the best, Jason

Re: [PATCH v4.16-rc6 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

Good day - I believe the last patch I sent, with $subject, addresses all concerns raised so far by reviewers, and complies with all kernel coding standards . Please, it would be most helpful if you could let me know whether the patch is now acceptable and will be applied at some stage or not -

[PATCH v4.16-rc6 (1)] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

d by H.J. Liu, was not applied first - Sorry! Thanks & Best Regards, Jason Vas Dias

[PATCH v4.16-rc6 1/1] x86/vdso: VDSO should handle clock_gettime(CLOCK_MONOTONIC_RAW) without syscall

This patch implements clock_gettime(CLOCK_MONOTONIC_RAW,) calls entirely in the vDSO, without calling vdso_fallback_gettime() . It has been augmented to support compilation with or without -DRETPOLINE / $(RETPOLINE_CFLAGS) ; when compiled with -DRETPOLINE, not all functions

  1   2   >