* 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
* Frederic Weisbecker fweis...@gmail.com 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
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.
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
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
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
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
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
2013/2/7 Ingo Molnar mi...@kernel.org:
* Frederic Weisbecker fweis...@gmail.com wrote:
2013/2/7 Ingo Molnar mi...@kernel.org:
* Steven Rostedt rost...@goodmis.org 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
2013/2/7 Christoph Lameter c...@linux.com:
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 Fri, 2013-02-08 at 16:53 +0100, Frederic Weisbecker wrote:
2013/2/7 Christoph Lameter c...@linux.com:
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
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 c...@linux.com:
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
On Fri, 8 Feb 2013 16:53:17 +0100
Frederic Weisbecker fweis...@gmail.com wrote:
2013/2/7 Christoph Lameter c...@linux.com:
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
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. Multiple
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
* 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
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
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
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
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
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
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
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
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
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
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
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
* 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
* Frederic Weisbecker fweis...@gmail.com wrote:
2013/2/7 Ingo Molnar mi...@kernel.org:
* Steven Rostedt rost...@goodmis.org 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
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:
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 the
* Christoph Lameter c...@linux.com 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
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 causing too
* Steven Rostedt rost...@goodmis.org 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
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
On Thu, 2013-02-07 at 12:10 +0100, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org 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 Ingo Molnar mi...@kernel.org:
* Steven Rostedt rost...@goodmis.org 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
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
2013/2/7 Steven Rostedt rost...@goodmis.org:
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
2013/2/7 Steven Rostedt rost...@goodmis.org:
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
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 rost...@goodmis.org 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
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 be
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 make it a
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,
2013/2/7 Steven Rostedt rost...@goodmis.org:
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
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 wholly on
2013/2/7 Steven Rostedt rost...@goodmis.org:
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
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
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
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
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 full
56 matches
Mail list logo
