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 a requested module is b
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 - or
This patch implements clock_gettime(CLOCK_MONOTONIC_RAW,&ts) 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 c
now the
subject of https://bugzilla.kernel.org/show_bug.cgi?id=199129,
raised by H.J. Liu, was not applied first - Sorry!
Thanks & Best Regards,
Jason Vas Dias
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 \
This patch makes the vDSO handle clock_gettime(CLOCK_MONOTONIC_RAW,&ts)
calls in the same way it handles clock_gettime(CLOCK_MONOTONIC,&ts)
calls,
reducing latency from @ 200-1000ns to @ 20ns.
It has been resent and augmented to support compilation with
-DRET
MONOTONIC_RAW,&ts)
calls - after the patch, the same 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
On 18/03/2018, Jason Vas Dias wrote:
(should have CC'ed to list, sorry)
> On 17/03/2018, Andi Kleen wrote:
>>
>> That's quite a mischaracterization of the issue. gcc works as intended,
>> but the kernel did not correctly supply a indirect call retpoline thunk
>&
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
Tota
e Latency' output produced
by 'timer_latency.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
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
asured for
clock_gettime(CLOCK_MONOTONIC_RAW,&ts)
calls - after the patch, the same call on the same machine
has a latency of @ 20ns.
Thanks & Best Regards,
Jason Vas Dias
This patch makes the vDSO handle clock_gettime(CLOCK_MONOTONIC_RAW,&ts)
calls in the same way it handles clock_gettime(CLOCK_MONOTONIC,&ts)
calls,
reducing latency from @ 200-1000ns to @ 20ns.
diff --git a/arch/x86/entry/vdso/vclock_gettime.c
b/arch/x86/entry/vdso/vc
Good day -
RE:
On 15/03/2018, Thomas Gleixner wrote:
> On Thu, 15 Mar 2018, Jason Vas Dias wrote:
>> On 15/03/2018, Thomas Gleixner wrote:
>> > On Thu, 15 Mar 2018, jason.vas.d...@gmail.com wrote:
>> >
>> >> Resent to address reviewer comments.
>>
r kernels 3.10.0-21 and 4.9.65-rt23 (ARM) 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,&ts)
calls - after the patch, the same call on the same machine
has a latency of @ 20ns.
Thanks & Best Regards,
Jason Vas Dias
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 s
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 this turns out to be j
3.10.0-21 and 4.9.65-rt23 (ARM) are attached to bug
#198161.
Thanks & Best Regards,
Jason Vas Dias
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 vread_tsc_raw(v
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 st
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 (&VVAR(vsysca
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 do
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 st
quot;optional" .
Patch #2 makes clock_gettime(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
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 vread_tsc_raw(v
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 (&VVAR(vsyscall
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
>
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
vdso_vclock_gettime_CLOCK_MONOTONIC_RAW-4
it.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
.
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 u
_RAW in VDSO using
existing rdtsc_ordered() , and the 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/vcloc
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
iew issues -
the next patch will add the rdtscp() function .
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-rc
ace TSC readers .
Resent : Oops, in previous version 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-
d a getter function in the VDSO that can optionally be 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
d a getter function in the VDSO that can optionally be 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-
eatly
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-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-
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
n of emacs Lisp cc-mode hooks in
Documentation/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,
Jas
n of emacs Lisp cc-mode hooks in
Documentation/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
l
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 &
ainst Linus' latest 4.16-rc4 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
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: Binary
t Linus' latest 4.16-rc4 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,
On 08/03/2018, Thomas Gleixner 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-space code -
>> but
Handling clock_gettime( CLOCK_MONOTONIC_RAW, ×pec)
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, &ts)
by issuing rdt
On 06/03/2018, Thomas Gleixner 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 subject line and the subject lin
P 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 able
to either measure an NTP adjusted time value, or a time value
difference of greater
than 1000ns with any accuracy, on a modern Intel CPU whose TSC ticks 2.8 times
per nanosecond (picosecond resolution is theoretically possible).
Please, include something like the above patch in future Linux versions.
Thanks & Best Regards,
Jason Vas Dias
On 13/02/2018, Jason Vas Dias 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 attempt to count all of :
> PERF_COUNT_HW_BRANCH_INSTR
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
PERF_COUNT_HW_BRANCH_MISSE
SC tick period by 2^24 nanoseconds!
Is this a bug or intentional ? 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
n that page ,
> & eventually a single copy of the tzdata could be used by both kernel
> & user-space.
> That is what I am working towards. Any plans to make linux real-time tsc
> clock user-friendly ?
>
>
>
> On 22/02/2017, Jason Vas Dias wrote:
>> Yes, m
me tsc
clock user-friendly ?
On 22/02/2017, Jason Vas Dias 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 . This is p
my two-cents 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 wrote:
> On 22/02/2017, Jason Vas Dias wrote:
>> RE:
>>>> 4.10 has new code which utilizes the TSC_ADJUST
On 22/02/2017, Jason Vas Dias 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!
>
> I have attached an upd
x27; & 'mult' +
'shift' values via sysfs.
Regards,
Jason.
On 21/02/2017, Jason Vas Dias 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 timestam
)
ia64_tsc_calc_mult_shift( &_ia64_tsc_mult, &_ia64_tsc_shift);
register U64_t cycles = IA64_tsc_ticks_since_start();
register U64_t ns = ((cycles *((UL_t)_ia64_tsc_mult))>>_ia64_tsc_shift);
return( (((ns / NSEC_PER_SEC)&0xUL) << 32) | ((ns %
NSEC_PER_SEC)&0x
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 a/arch/x86
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 sc
o" 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 wrote:
> [changed linux-config to linux-kbuild list]
>
>
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
docum
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 +
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 :
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 wrote:
> Good day -
> I am trying to build the latest RHEL kernel from the source RPM,
> but this fails because the &q
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
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 wrote:
> Good day -
>
> I wonder if there is a
btr /mnt/btr/root-0
$ btrfs subvolume 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&q
ok for libunwind and the Android
SDK headers,
which are not part of the kernel's BuildRequires .
Thanks in advance for any helpful 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/
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
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
ATCH: 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
Kernel
x
Jason Vas Dias
Jul 9 (5 days ago)
Reply
to Rusty, linux-kernel, Andreas, Matthew,
of what temperature
is reported .
On Mon, Jul 9, 2012 at 1:30 AM, Rusty Russell wrote:
> On Sun, 8 Jul 2012 19:50:54 +0100, Jason Vas Dias
> wrote:
>> This patch adds a new acpi.thermal.temp_b4_trip = 1 settting, which
>> causes the temperature
>> to be set before eva
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 patc
Sorry, of course the commit I backed out was :
9bcb8118965ab4631a65ee0726e6518f75cda6c5.
On Sat, Jul 7, 2012 at9bcb8118965ab4631a65ee0726e6518f75cda6c5. 3:40
PM, Jason Vas Dias wrote:
> I can confirm that the AMD Turion X2 2.2Ghz HP Compaq 6715b
> "business" x86_64 k8 dual-co
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)
On Wed, May 30, 2012 at 1:43 PM, An
74 matches
Mail list logo
