similar to: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support

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

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

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

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

On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti <mtosatti 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

On Thu, Oct 4, 2018 at 9:43 AM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > On Wed, Oct 03, 2018 at 03:32:08PM -0700, Andy Lutomirski wrote: > > On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti <mtosatti at redhat.com> wrote: > > > > > > On Tue, Oct 02, 2018 at 10:15:49PM -0700, Andy Lutomirski wrote: > > > > Hi Vitaly, Paolo, Radim,

On Wed, Oct 03, 2018 at 11:22:58AM +0200, Vitaly Kuznetsov wrote: > Andy Lutomirski <luto at kernel.org> writes: > > > 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,

> 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 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()

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

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

On Wed, Oct 03, 2018 at 03:32:08PM -0700, Andy Lutomirski wrote: > On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti <mtosatti 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>

On Wed, Oct 03, 2018 at 03:32:08PM -0700, Andy Lutomirski wrote: > On Wed, Oct 3, 2018 at 12:01 PM Marcelo Tosatti <mtosatti 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>

Andy Lutomirski <luto at kernel.org> writes: > 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

Andy Lutomirski <luto at kernel.org> writes: > 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

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 to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

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 to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

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 to use retpolines. If jump tables are disabled it adds yet another conditional to the existing

> 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