search for: clock_tai

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so > the array slot 3 is unused > - CLOCK_TAI is id 11 which results in 3...

> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > With the storage array in place it's now trivial to support CLOCK_TAI in > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > of the fact that: > > - CLOCK ids are set in stone > - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so > the array slot 3 is unused > - CLOCK_TAI is id 11 which results in 3...

With the storage array in place it's now trivial to support CLOCK_TAI in the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use of the fact that: - CLOCK ids are set in stone - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so the array slot 3 is unused - CLOCK_TAI is id 11 which results in 3 when masked with 0x3 Add the m...

On Fri, 14 Sep 2018, Andy Lutomirski wrote: > > On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > > > With the storage array in place it's now trivial to support CLOCK_TAI in > > the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use > > of the fact that: > > > > - CLOCK ids are set in stone > > - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so > > the array slot 3 is unused > > - CLO...

...7 AM, Thomas Gleixner <tglx at linutronix.de> wrote: > > On Fri, 14 Sep 2018, Andy Lutomirski wrote: >>> On Sep 14, 2018, at 5:50 AM, Thomas Gleixner <tglx at linutronix.de> wrote: >>> >>> With the storage array in place it's now trivial to support CLOCK_TAI in >>> the vdso. Instead of extending the array to accomodate CLOCK_TAI, make use >>> of the fact that: >>> >>> - CLOCK ids are set in stone >>> - CLOCK_THREAD_CPUTIME is never going to be supported in the VDSO so >>> the array slot 3 is unuse...

On Fri, 14 Sep 2018, Florian Weimer wrote: > On 09/14/2018 02:50 PM, Thomas Gleixner wrote: > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > > implementation, which extended the clockid switch case and added yet > > another slightly different copy of the same code. > > > > Especially the extended switch case is problematic as the compiler tends to > > generate a jump t...

On Fri, Sep 14, 2018 at 02:56:46PM +0200, Florian Weimer wrote: > On 09/14/2018 02:50 PM, Thomas Gleixner wrote: > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > > implementation, which extended the clockid switch case and added yet > > another slightly different copy of the same code. > > > > Especially the extended switch case is problematic as the compiler tends to > > generate a jump t...

On Fri, 14 Sep 2018, Florian Weimer wrote: > On 09/14/2018 03:05 PM, Thomas Gleixner wrote: > > On Fri, 14 Sep 2018, Florian Weimer wrote: > > > > > On 09/14/2018 02:50 PM, Thomas Gleixner wrote: > > > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > > > > implementation, which extended the clockid switch case and added yet > > > > another slightly different copy of the same code. > > > > > > > > Especially the extended switch case is problematic as the compi...

Hi Vitaly, Paolo, Radim, etc., On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner <tglx at linutronix.de> wrote: > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > implementation, which extended the clockid switch case and added yet > another slightly different copy of the same code. > > Especially the extended switch case is problematic as the compiler tends to > generate a jump table which then requires t...

On Fri, Sep 14, 2018 at 2:52 PM Thomas Gleixner <tglx at linutronix.de> wrote: > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > implementation, which extended the clockid switch case and added yet > another slightly different copy of the same code. > > Especially the extended switch case is problematic as the compiler tends to > generate a jump table which then requires t...

...i at redhat.com> wrote: > > On Tue, Oct 02, 2018 at 10:15:49PM -0700, Andy Lutomirski wrote: > > Hi Vitaly, Paolo, Radim, etc., > > > > On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner <tglx at linutronix.de> wrote: > > > > > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > > > implementation, which extended the clockid switch case and added yet > > > another slightly different copy of the same code. > > > > > > Especially the extended switch case is problematic as the compiler tends to > &gt...

> On Oct 3, 2018, at 5:01 AM, Vitaly Kuznetsov <vkuznets at redhat.com> wrote: > > Andy Lutomirski <luto at amacapital.net> writes: > >>> On Oct 3, 2018, at 2:22 AM, Vitaly Kuznetsov <vkuznets at redhat.com> wrote: >>> >>> Andy Lutomirski <luto at kernel.org> writes: >>> >>>> Hi Vitaly, Paolo, Radim, etc.,

On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: > I was hoping to hear this from you :-) If I am to suggest how we can > move forward I'd propose: > - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling > is supported). > - Check if non-masterclock mode is still needed. E.g. HyperV's TSC page > clocksource is a single page for the whole

On 04/10/2018 09:54, Vitaly Kuznetsov wrote: > - Check if pure TSC can be used on SkyLake+ systems (where TSC scaling > is supported). Not if you want to migrate to pre-Skylake systems. > - Check if non-masterclock mode is still needed. E.g. HyperV's TSC page > clocksource is a single page for the whole VM, not a per-cpu thing. Can > we think that all the buggy hardware is

On Thu, Oct 04, 2018 at 07:00:45AM -0700, Andy Lutomirski wrote: > > On Oct 4, 2018, at 1:11 AM, Peter Zijlstra <peterz at infradead.org> wrote: > > > >> On Thu, Oct 04, 2018 at 09:54:45AM +0200, Vitaly Kuznetsov wrote: > >> I was hoping to hear this from you :-) If I am to suggest how we can > >> move forward I'd propose: > >> - Check if

For better or for worse, I'm trying to understand this code. So far, I've come up with this patch: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso-tglx&id=14fd71e12b1c4492a06f368f75041f263e6862bf Is it correct, or am I missing some subtlety?

On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote: > > For better or for worse, I'm trying to understand this code. So far, > > I've come up with this patch: > > > >

On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > On Sat, Oct 06, 2018 at 03:28:05PM -0700, Andy Lutomirski wrote: > > On Sat, Oct 6, 2018 at 1:29 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > > > On Thu, Oct 04, 2018 at 03:15:32PM -0700, Andy Lutomirski wrote: > > > > For better or for worse,

On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote: > > On Mon, Oct 8, 2018 at 8:27 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > I read the comment three more times and even dug through the git > > history. It seems like what you're saying is that,

On Thu, Oct 11, 2018 at 3:28 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > On Tue, Oct 09, 2018 at 01:09:42PM -0700, Andy Lutomirski wrote: > > On Tue, Oct 9, 2018 at 8:28 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > > > On Mon, Oct 08, 2018 at 10:38:22AM -0700, Andy Lutomirski wrote: > > > > On Mon, Oct 8, 2018 at 8:27