* Frederic Weisbecker wrote:
> > I'm worried about the proliferation of not easily separable
> > config options. We already have way too many timer and
> > scheduler options to begin with.
>
> Like Steve said, this is for overhead reasons. The syscall
> uses the slow path so that's ok. But w
On Fri, 8 Feb 2013, Clark Williams wrote:
> I was a little apprehensive when you started talking about multiple
> tasks in Adaptive NOHZ mode on a core but the more I started thinking
> about it, I realized that we might end up in a cooperative multitasking
> mode with no tick at all going. Multip
On Fri, 8 Feb 2013 16:53:17 +0100
Frederic Weisbecker wrote:
> 2013/2/7 Christoph Lameter :
> > On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
> >
> >> Not with hrtick.
> >
> > hrtick? Did we not already try that a couple of years back and it turned
> > out that the overhead of constantly reprogr
On Fri, 8 Feb 2013, Steven Rostedt wrote:
> On Fri, 2013-02-08 at 16:53 +0100, Frederic Weisbecker wrote:
> > 2013/2/7 Christoph Lameter :
> > > On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
> > >
> > >> Not with hrtick.
> > >
> > > hrtick? Did we not already try that a couple of years back and i
On Fri, 2013-02-08 at 16:53 +0100, Frederic Weisbecker wrote:
> 2013/2/7 Christoph Lameter :
> > On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
> >
> >> Not with hrtick.
> >
> > hrtick? Did we not already try that a couple of years back and it turned
> > out that the overhead of constantly reprogra
2013/2/7 Christoph Lameter :
> On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
>
>> Not with hrtick.
>
> hrtick? Did we not already try that a couple of years back and it turned
> out that the overhead of constantly reprogramming a timer via the PCI bus
> was causing too much of a performance regres
2013/2/7 Ingo Molnar :
>
> * Frederic Weisbecker wrote:
>
>> 2013/2/7 Ingo Molnar :
>> >
>> > * Steven Rostedt wrote:
>> >
>> >> I'll reply to this as I come up with comments.
>> >>
>> >> First thing is, don't call it NO_HZ_FULL. A better name would
>> >> be NO_HZ_CPU. I would like to reserve NO_
On Thu, 2013-02-07 at 19:14 +, Christoph Lameter wrote:
> On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
>
> > Not with hrtick.
>
> hrtick? Did we not already try that a couple of years back and it turned
> out that the overhead of constantly reprogramming a timer via the PCI bus
> was causi
* Christoph Lameter wrote:
> On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
>
> > Not with hrtick.
>
> hrtick? Did we not already try that a couple of years back and
> it turned out that the overhead of constantly reprogramming a
> timer via the PCI bus was causing too much of a performance
On Thu, 2013-02-07 at 20:07 +0100, Ingo Molnar wrote:
> Could we just simplify things and make this an unconditional
> option of NO_HZ? Any reason why we'd want to make this
> configurable, other than debugging?
I think the worry is the overhead that is required to keep it active. It
requires t
On Thu, 7 Feb 2013, Frederic Weisbecker wrote:
> Not with hrtick.
hrtick? Did we not already try that a couple of years back and it turned
out that the overhead of constantly reprogramming a timer via the PCI bus
was causing too much of a performance regression?
--
To unsubscribe from this list:
* Frederic Weisbecker wrote:
> 2013/2/7 Ingo Molnar :
> >
> > * Steven Rostedt wrote:
> >
> >> I'll reply to this as I come up with comments.
> >>
> >> First thing is, don't call it NO_HZ_FULL. A better name would
> >> be NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we
> >> totally remove
2013/2/7 Steven Rostedt :
> On Thu, 2013-02-07 at 17:45 +0100, Frederic Weisbecker wrote:
>
>> >
>> > config NO_HZ_TASK
>> > bool "Stop tick on specified CPUs when single task is running"
>> > default n
>> > depends on NO_HZ
>>
>> Ok I launched another debate about that sing
On Thu, Feb 07, 2013 at 12:06:21PM -0500, Steven Rostedt wrote:
> On Thu, 2013-02-07 at 08:30 -0800, Paul E. McKenney wrote:
>
> > I suspect that removal of jiffies from the kernel will take a few stages,
> > with RCU being one of the laggards for awhile. Making RCU's state
> > machine depend who
2013/2/7 Steven Rostedt :
> On Thu, 2013-02-07 at 17:41 +0100, Frederic Weisbecker wrote:
>
>> I'm not convinced that "single task" must be a fundamental component
>> of this. It's an implementation detail. We should be able to keep the
>> tick off in the future when more than one task are on the r
On Thu, 2013-02-07 at 08:30 -0800, Paul E. McKenney wrote:
> I suspect that removal of jiffies from the kernel will take a few stages,
> with RCU being one of the laggards for awhile. Making RCU's state
> machine depend wholly on process-based execution will take some care
> and experimentation,
On Thu, 2013-02-07 at 17:45 +0100, Frederic Weisbecker wrote:
> >
> > config NO_HZ_TASK
> > bool "Stop tick on specified CPUs when single task is running"
> > default n
> > depends on NO_HZ
>
> Ok I launched another debate about that single task thing. I wish we
> don't ma
On Thu, 2013-02-07 at 17:41 +0100, Frederic Weisbecker wrote:
> I'm not convinced that "single task" must be a fundamental component
> of this. It's an implementation detail. We should be able to keep the
> tick off in the future when more than one task are on the runqueue and
> hrtick is on. May
On Thu, Feb 07, 2013 at 11:12:00AM -0500, Steven Rostedt wrote:
> On Thu, 2013-02-07 at 12:10 +0100, Ingo Molnar wrote:
> > * Steven Rostedt wrote:
> >
> > > I'll reply to this as I come up with comments.
> > >
> > > First thing is, don't call it NO_HZ_FULL. A better name would
> > > be NO_HZ_C
2013/2/7 Steven Rostedt :
> On Thu, 2013-02-07 at 17:25 +0100, Frederic Weisbecker wrote:
>
>> At least for now we seem to agree on CONFIG_NO_HZ_IDLE and keep
>> CONFIG_NO_HZ for compatibility. Are you ok with that? If so I'll send
>> a patch.
>
> I believe that Ingo was suggesting to have CONFIG_N
2013/2/7 Steven Rostedt :
> I'll reply to this as I come up with comments.
>
> First thing is, don't call it NO_HZ_FULL. A better name would be
> NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we totally remove
> jiffies :-)
I'm not sure we'll ever be able to completely remove the tick, even i
On Thu, 2013-02-07 at 17:25 +0100, Frederic Weisbecker wrote:
> At least for now we seem to agree on CONFIG_NO_HZ_IDLE and keep
> CONFIG_NO_HZ for compatibility. Are you ok with that? If so I'll send
> a patch.
I believe that Ingo was suggesting to have CONFIG_NO_HZ give options to
what type of c
2013/2/7 Ingo Molnar :
>
> * Steven Rostedt wrote:
>
>> I'll reply to this as I come up with comments.
>>
>> First thing is, don't call it NO_HZ_FULL. A better name would
>> be NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we
>> totally remove jiffies :-)
>
> I don't think we want yet another
On Thu, 2013-02-07 at 12:10 +0100, Ingo Molnar wrote:
> * Steven Rostedt wrote:
>
> > I'll reply to this as I come up with comments.
> >
> > First thing is, don't call it NO_HZ_FULL. A better name would
> > be NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we
> > totally remove jiffies :-)
On Thu, 7 Feb 2013, Ingo Molnar wrote:
> Agreed?
Yes and please also change the texts in Kconfig to accurately describe
what happens to the timer tick.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo i
* Steven Rostedt wrote:
> I'll reply to this as I come up with comments.
>
> First thing is, don't call it NO_HZ_FULL. A better name would
> be NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we
> totally remove jiffies :-)
I don't think we want yet another config option named in a
weird
I'll reply to this as I come up with comments.
First thing is, don't call it NO_HZ_FULL. A better name would be
NO_HZ_CPU. I would like to reserve NO_HZ_FULL when we totally remove
jiffies :-)
And the kconfig help should probably call it "Adaptive tickless" or
"Tickless for single tasks". The ful
Hi,
The support for printk and cputime accounting to work on full dynticks CPUs have
been merged in -tip tree and is likely deemed for the 3.9 merge window. So this
new release is a rebase against the relevant branches in -tip and v3.8-rc6.
The remaining amount of patches has thus quite schrinked
28 matches
Mail list logo
