On Fri, Jul 05, 2013 at 11:50:05PM +0200, Thomas Gleixner wrote:
> On Fri, 5 Jul 2013, Peter Zijlstra wrote:
> > On Fri, Jul 05, 2013 at 05:24:09PM +0200, Thomas Gleixner wrote:
> > > See arch/x86/kernel/tsc.c
> > >
> > > We disable the watchdog for the TSC when tsc_clocksource_reliable is
> > >
On Sat, Jul 06, 2013 at 12:17:46AM +0200, Thomas Gleixner wrote:
> Good news! 10 years is way less than eternity and just before
> retirement :)
You know that after the 10 years they'll come up with an even uglier
platform-differentiation-fiddle-with-dong-while-smoking-crack-crap which
will even
On Sat, Jul 06, 2013 at 12:17:46AM +0200, Thomas Gleixner wrote:
Good news! 10 years is way less than eternity and just before
retirement :)
You know that after the 10 years they'll come up with an even uglier
platform-differentiation-fiddle-with-dong-while-smoking-crack-crap which
will even
On Fri, Jul 05, 2013 at 11:50:05PM +0200, Thomas Gleixner wrote:
On Fri, 5 Jul 2013, Peter Zijlstra wrote:
On Fri, Jul 05, 2013 at 05:24:09PM +0200, Thomas Gleixner wrote:
See arch/x86/kernel/tsc.c
We disable the watchdog for the TSC when tsc_clocksource_reliable is
set.
On Fri, 5 Jul 2013, Borislav Petkov wrote:
> On Fri, Jul 05, 2013 at 11:50:05PM +0200, Thomas Gleixner wrote:
> > Yeah, but our well justified paranoia still prevents us from trusting
> > these CPU flags. Maybe some day BIOS is going to be replaced by
> > something useful. You know: Hope springs
On Fri, Jul 05, 2013 at 11:50:05PM +0200, Thomas Gleixner wrote:
> Yeah, but our well justified paranoia still prevents us from trusting
> these CPU flags. Maybe some day BIOS is going to be replaced by
> something useful. You know: Hope springs eternal
Not in the next 10 yrs at least if one
On Fri, 5 Jul 2013, Peter Zijlstra wrote:
> On Fri, Jul 05, 2013 at 05:24:09PM +0200, Thomas Gleixner wrote:
> > See arch/x86/kernel/tsc.c
> >
> > We disable the watchdog for the TSC when tsc_clocksource_reliable is
> > set.
> >
> > tsc_clocksource_reliable is set when:
> >
> > - you add
On Fri, Jul 05, 2013 at 05:24:09PM +0200, Thomas Gleixner wrote:
> See arch/x86/kernel/tsc.c
>
> We disable the watchdog for the TSC when tsc_clocksource_reliable is
> set.
>
> tsc_clocksource_reliable is set when:
>
> - you add tsc=reliable to the kernel command line
Ah, I didn't know about
On Fri, 5 Jul 2013, Peter Zijlstra wrote:
> On Fri, Jul 05, 2013 at 04:23:33PM +0200, Frederic Weisbecker wrote:
> > Nope, I haven't touched that. I prefer not to fiddle with unstable
> > clocksource for now :)
> >
> > As for unstable TSCs, if sched_clock_tick() needs to be fed, we simply
> >
On Fri, Jul 05, 2013 at 04:23:33PM +0200, Frederic Weisbecker wrote:
> Nope, I haven't touched that. I prefer not to fiddle with unstable
> clocksource for now :)
>
> As for unstable TSCs, if sched_clock_tick() needs to be fed, we simply
> don't stop the tick.
Not entirely the same thing; I
2013/7/4 Peter Zijlstra :
> On Thu, Jul 04, 2013 at 01:34:13PM +0800, Alex Shi wrote:
>
>> If the tsc is marked as constant and nonstop, could we set it as system
>> clocksource when do tsc register? w/o checking it on clocksource_watchdog?
>
> I'd not do that; the BIOS can still screw you over,
On 07/05/2013 01:58 PM, Thomas Gleixner wrote:
>> >
>> > Ingo had merged your branch into sched/core. :)
>> >
>> > commit f9bed7021710a3e45c331f7d7781de914cc1b939
>> > Merge: 7e76057 67dd331
>> > Author: Ingo Molnar
>> > Date: Wed May 29 11:21:59 2013 +0200
>> >
>> > Merge branch
On 07/05/2013 01:58 PM, Thomas Gleixner wrote:
Ingo had merged your branch into sched/core. :)
commit f9bed7021710a3e45c331f7d7781de914cc1b939
Merge: 7e76057 67dd331
Author: Ingo Molnar mi...@kernel.org
Date: Wed May 29 11:21:59 2013 +0200
Merge branch 'timers/urgent'
2013/7/4 Peter Zijlstra pet...@infradead.org:
On Thu, Jul 04, 2013 at 01:34:13PM +0800, Alex Shi wrote:
If the tsc is marked as constant and nonstop, could we set it as system
clocksource when do tsc register? w/o checking it on clocksource_watchdog?
I'd not do that; the BIOS can still screw
On Fri, Jul 05, 2013 at 04:23:33PM +0200, Frederic Weisbecker wrote:
Nope, I haven't touched that. I prefer not to fiddle with unstable
clocksource for now :)
As for unstable TSCs, if sched_clock_tick() needs to be fed, we simply
don't stop the tick.
Not entirely the same thing; I thought
On Fri, 5 Jul 2013, Peter Zijlstra wrote:
On Fri, Jul 05, 2013 at 04:23:33PM +0200, Frederic Weisbecker wrote:
Nope, I haven't touched that. I prefer not to fiddle with unstable
clocksource for now :)
As for unstable TSCs, if sched_clock_tick() needs to be fed, we simply
don't stop
On Fri, Jul 05, 2013 at 05:24:09PM +0200, Thomas Gleixner wrote:
See arch/x86/kernel/tsc.c
We disable the watchdog for the TSC when tsc_clocksource_reliable is
set.
tsc_clocksource_reliable is set when:
- you add tsc=reliable to the kernel command line
Ah, I didn't know about that
On Fri, 5 Jul 2013, Peter Zijlstra wrote:
On Fri, Jul 05, 2013 at 05:24:09PM +0200, Thomas Gleixner wrote:
See arch/x86/kernel/tsc.c
We disable the watchdog for the TSC when tsc_clocksource_reliable is
set.
tsc_clocksource_reliable is set when:
- you add tsc=reliable to the
On Fri, Jul 05, 2013 at 11:50:05PM +0200, Thomas Gleixner wrote:
Yeah, but our well justified paranoia still prevents us from trusting
these CPU flags. Maybe some day BIOS is going to be replaced by
something useful. You know: Hope springs eternal
Not in the next 10 yrs at least if one
On Fri, 5 Jul 2013, Borislav Petkov wrote:
On Fri, Jul 05, 2013 at 11:50:05PM +0200, Thomas Gleixner wrote:
Yeah, but our well justified paranoia still prevents us from trusting
these CPU flags. Maybe some day BIOS is going to be replaced by
something useful. You know: Hope springs
On Fri, 5 Jul 2013, Alex Shi wrote:
> On 07/05/2013 04:27 AM, Thomas Gleixner wrote:
> We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
> > And that branch does NOT have that commit included. So how can you see
> > a regression on a branch caused by a commit NOT
On 07/05/2013 04:27 AM, Thomas Gleixner wrote:
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
> And that branch does NOT have that commit included. So how can you see
> a regression on a branch caused by a commit NOT included into that
> branch?
>
> The offending
On Thu, 4 Jul 2013, Davidlohr Bueso wrote:
> On Thu, 2013-07-04 at 13:00 +0200, Thomas Gleixner wrote:
> > On Thu, 4 Jul 2013, Alex Shi wrote:
> >
> > > We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
> > > like oltp, tbench, hackbench etc. and bisected the commit
On Thu, 2013-07-04 at 13:00 +0200, Thomas Gleixner wrote:
> On Thu, 4 Jul 2013, Alex Shi wrote:
>
> > We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
> > like oltp, tbench, hackbench etc. and bisected the commit 5d33b883ae
> > cause this regression. Due to this commit,
On Thu, 4 Jul 2013, Alex Shi wrote:
> We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
> like oltp, tbench, hackbench etc. and bisected the commit 5d33b883ae
> cause this regression. Due to this commit, the clocksource was changed
> to hpet from tsc even tsc will be set
On 07/04/2013 03:58 PM, Peter Zijlstra wrote:
> On Thu, Jul 04, 2013 at 01:34:13PM +0800, Alex Shi wrote:
>
>> If the tsc is marked as constant and nonstop, could we set it as system
>> clocksource when do tsc register? w/o checking it on clocksource_watchdog?
>
> I'd not do that; the BIOS can
On Thu, Jul 04, 2013 at 01:34:13PM +0800, Alex Shi wrote:
> If the tsc is marked as constant and nonstop, could we set it as system
> clocksource when do tsc register? w/o checking it on clocksource_watchdog?
I'd not do that; the BIOS can still screw you over, we need some validation.
That
On Thu, Jul 04, 2013 at 01:34:13PM +0800, Alex Shi wrote:
If the tsc is marked as constant and nonstop, could we set it as system
clocksource when do tsc register? w/o checking it on clocksource_watchdog?
I'd not do that; the BIOS can still screw you over, we need some validation.
That said;
On 07/04/2013 03:58 PM, Peter Zijlstra wrote:
On Thu, Jul 04, 2013 at 01:34:13PM +0800, Alex Shi wrote:
If the tsc is marked as constant and nonstop, could we set it as system
clocksource when do tsc register? w/o checking it on clocksource_watchdog?
I'd not do that; the BIOS can still
On Thu, 4 Jul 2013, Alex Shi wrote:
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
like oltp, tbench, hackbench etc. and bisected the commit 5d33b883ae
cause this regression. Due to this commit, the clocksource was changed
to hpet from tsc even tsc will be set
On Thu, 2013-07-04 at 13:00 +0200, Thomas Gleixner wrote:
On Thu, 4 Jul 2013, Alex Shi wrote:
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
like oltp, tbench, hackbench etc. and bisected the commit 5d33b883ae
cause this regression. Due to this commit, the
On Thu, 4 Jul 2013, Davidlohr Bueso wrote:
On Thu, 2013-07-04 at 13:00 +0200, Thomas Gleixner wrote:
On Thu, 4 Jul 2013, Alex Shi wrote:
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
like oltp, tbench, hackbench etc. and bisected the commit 5d33b883ae
On 07/05/2013 04:27 AM, Thomas Gleixner wrote:
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
And that branch does NOT have that commit included. So how can you see
a regression on a branch caused by a commit NOT included into that
branch?
The offending commit is
On Fri, 5 Jul 2013, Alex Shi wrote:
On 07/05/2013 04:27 AM, Thomas Gleixner wrote:
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
And that branch does NOT have that commit included. So how can you see
a regression on a branch caused by a commit NOT included into
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
like oltp, tbench, hackbench etc. and bisected the commit 5d33b883ae
cause this regression. Due to this commit, the clocksource was changed
to hpet from tsc even tsc will be set CLOCK_SOURCE_VALID_FOR_HRES later
in
We find some benchmarks drop a lot on tip/sched/core on many Intel boxes,
like oltp, tbench, hackbench etc. and bisected the commit 5d33b883ae
cause this regression. Due to this commit, the clocksource was changed
to hpet from tsc even tsc will be set CLOCK_SOURCE_VALID_FOR_HRES later
in
36 matches
Mail list logo
