On Mon, 25 Mar 2013, Frederic Weisbecker wrote:
> > The vm kernel threads do no useful work if no system calls are being done.
> > If there is no kernel action then they can be deferred indefinitely.
> >
>
> We can certainly add some user deferrable timer_list. But that's going
> to be for
2013/3/25 Christoph Lameter :
> On Mon, 25 Mar 2013, Frederic Weisbecker wrote:
>
>> > The vm kernel threads do no useful work if no system calls are being done.
>> > If there is no kernel action then they can be deferred indefinitely.
>> >
>>
>> We can certainly add some user deferrable
On Fri, 22 Mar 2013, Paul E. McKenney wrote:
> On Fri, Mar 22, 2013 at 02:38:58PM +, Christoph Lameter wrote:
> > On Thu, 21 Mar 2013, Paul E. McKenney wrote:
> >
> > > So, how long of busy periods are you contemplating for your SCHED_FIFO
> > > threads? Is it possible to tune/adjust the
2013/3/25 Christoph Lameter :
> On Fri, 22 Mar 2013, Paul E. McKenney wrote:
>
>> On Fri, Mar 22, 2013 at 02:38:58PM +, Christoph Lameter wrote:
>> > On Thu, 21 Mar 2013, Paul E. McKenney wrote:
>> >
>> > > So, how long of busy periods are you contemplating for your SCHED_FIFO
>> > > threads?
2013/3/25 Christoph Lameter c...@linux.com:
On Fri, 22 Mar 2013, Paul E. McKenney wrote:
On Fri, Mar 22, 2013 at 02:38:58PM +, Christoph Lameter wrote:
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
So, how long of busy periods are you contemplating for your SCHED_FIFO
threads? Is
On Fri, 22 Mar 2013, Paul E. McKenney wrote:
On Fri, Mar 22, 2013 at 02:38:58PM +, Christoph Lameter wrote:
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
So, how long of busy periods are you contemplating for your SCHED_FIFO
threads? Is it possible to tune/adjust the offending
2013/3/25 Christoph Lameter c...@linux.com:
On Mon, 25 Mar 2013, Frederic Weisbecker wrote:
The vm kernel threads do no useful work if no system calls are being done.
If there is no kernel action then they can be deferred indefinitely.
We can certainly add some user deferrable
On Mon, 25 Mar 2013, Frederic Weisbecker wrote:
The vm kernel threads do no useful work if no system calls are being done.
If there is no kernel action then they can be deferred indefinitely.
We can certainly add some user deferrable timer_list. But that's going
to be for extreme
On Fri, Mar 22, 2013 at 11:37:55AM -0700, Kevin Hilman wrote:
> "Paul E. McKenney" writes:
>
> > On Thu, Mar 21, 2013 at 10:41:30AM -0700, Arjan van de Ven wrote:
> >> On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
> >> > o Use the "idle=poll" boot parameter. However, please note
> >> >
[...]
>> >
>> > In the meantime, one approach is to bind all these SCHED_OTHER tasks
>> > to designated housekeeping CPU(s) that don't run your main workload.
>>
>> One cannot bind kevent threads and other per cpu threads to another
>> processor. So right now there is no way to avoid this issue.
"Paul E. McKenney" writes:
> On Thu, Mar 21, 2013 at 10:41:30AM -0700, Arjan van de Ven wrote:
>> On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
>> >o Use the "idle=poll" boot parameter. However, please note
>> >that use of this parameter can cause your CPU to overheat,
>>
On Fri, Mar 22, 2013 at 02:38:58PM +, Christoph Lameter wrote:
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
>
> > So, how long of busy periods are you contemplating for your SCHED_FIFO
> > threads? Is it possible to tune/adjust the offending per-CPU ktheads
> > to wake up less frequently
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
> So, how long of busy periods are you contemplating for your SCHED_FIFO
> threads? Is it possible to tune/adjust the offending per-CPU ktheads
> to wake up less frequently than that time?
Test programs right now run 10 seconds. 30 seconds would
Christoph Lameter wrote:
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
>
> > > Yeah doing that right now but I'd like to see it handled without manual
> > > intervention.
> >
> > Given that RCU has no idea where you want them to run, some manual
> > intervention would most likely be required
Christoph Lameter wrote:
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
Yeah doing that right now but I'd like to see it handled without manual
intervention.
Given that RCU has no idea where you want them to run, some manual
intervention would most likely be required even if RCU
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
So, how long of busy periods are you contemplating for your SCHED_FIFO
threads? Is it possible to tune/adjust the offending per-CPU ktheads
to wake up less frequently than that time?
Test programs right now run 10 seconds. 30 seconds would
On Fri, Mar 22, 2013 at 02:38:58PM +, Christoph Lameter wrote:
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
So, how long of busy periods are you contemplating for your SCHED_FIFO
threads? Is it possible to tune/adjust the offending per-CPU ktheads
to wake up less frequently than that
Paul E. McKenney paul...@linux.vnet.ibm.com writes:
On Thu, Mar 21, 2013 at 10:41:30AM -0700, Arjan van de Ven wrote:
On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
o Use the idle=poll boot parameter. However, please note
that use of this parameter can cause your CPU to
[...]
In the meantime, one approach is to bind all these SCHED_OTHER tasks
to designated housekeeping CPU(s) that don't run your main workload.
One cannot bind kevent threads and other per cpu threads to another
processor. So right now there is no way to avoid this issue.
Yep, my
On Fri, Mar 22, 2013 at 11:37:55AM -0700, Kevin Hilman wrote:
Paul E. McKenney paul...@linux.vnet.ibm.com writes:
On Thu, Mar 21, 2013 at 10:41:30AM -0700, Arjan van de Ven wrote:
On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
o Use the idle=poll boot parameter. However, please
On 03/21/2013 10:45:07 AM, Arjan van de Ven wrote:
On 3/20/2013 5:27 PM, Steven Rostedt wrote:
I'm not sure I would recommend idle=poll either. It would certainly
work, but it goes to the other extreme. You think NO_HZ=n drains a
battery? Try idle=poll.
do not ever use idle=poll on anything
2013/3/21 Christoph Lameter :
> On Thu, 21 Mar 2013, Frederic Weisbecker wrote:
>
>> Sure, for now just don't use SCHED_FIFO and you will have a much more
>> extended dynticks coverage.
>
> Ah. Ok. Important information. That would mean no tick for the 2 second
> intervals between the vm stats
On Thu, 21 Mar 2013, Frederic Weisbecker wrote:
> Sure, for now just don't use SCHED_FIFO and you will have a much more
> extended dynticks coverage.
Ah. Ok. Important information. That would mean no tick for the 2 second
intervals between the vm stats etc. Much much better than now where we
On Thu, Mar 21, 2013 at 08:04:08PM +, Christoph Lameter wrote:
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
>
> > > Yeah doing that right now but I'd like to see it handled without manual
> > > intervention.
> >
> > Given that RCU has no idea where you want them to run, some manual
> >
2013/3/21 Christoph Lameter :
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
>> So, again, removing scheduling-clock interrupts in more situations is
>> a good future enhancement.
>
> The point here is that the check for a single runnable process is wrong
> because it accounts for tasks in all
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
> > Yeah doing that right now but I'd like to see it handled without manual
> > intervention.
>
> Given that RCU has no idea where you want them to run, some manual
> intervention would most likely be required even if RCU spawned them
> dynamically,
On Thu, 2013-03-21 at 18:53 +, Christoph Lameter wrote:
> On Thu, 21 Mar 2013, Steven Rostedt wrote:
>
> > For now, no, if more than one process is scheduled on the CPU, we fall
> > out of dynamic tick mode. In the future, we can add SCHED_FIFO task
> > scheduled in to trigger it. But lets
On Thu, 21 Mar 2013, Steven Rostedt wrote:
> For now, no, if more than one process is scheduled on the CPU, we fall
> out of dynamic tick mode. In the future, we can add SCHED_FIFO task
> scheduled in to trigger it. But lets conquer that after we successfully
> conquer the current changes.
Be
On Thu, Mar 21, 2013 at 02:44:22PM -0400, Steven Rostedt wrote:
> On Thu, 2013-03-21 at 10:15 -0700, Paul E. McKenney wrote:
>
> > > The OS always has some sched other tasks around that become runnable after
> > > a while (like for example the vm statistics update, or the notorious slab
> > >
On Thu, Mar 21, 2013 at 06:39:09PM +, Christoph Lameter wrote:
> On Thu, 21 Mar 2013, Paul E. McKenney wrote:
>
> > > Why are there multiple rcuo threads? Would a single thread that may be
> > > able to run on multiple cpus not be sufficient?
> >
> > In many cases, this would indeed be
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
> > Why are there multiple rcuo threads? Would a single thread that may be
> > able to run on multiple cpus not be sufficient?
>
> In many cases, this would indeed be sufficient. However, if you have
> enough CPUs posting RCU callbacks, then the
On Thu, 2013-03-21 at 10:15 -0700, Paul E. McKenney wrote:
> > The OS always has some sched other tasks around that become runnable after
> > a while (like for example the vm statistics update, or the notorious slab
> > scanning). As long as SCHED_FIFO is active and there is no process in the
> >
On Thu, Mar 21, 2013 at 07:01:01PM +0100, Frederic Weisbecker wrote:
> 2013/3/21 Steven Rostedt :
> > [ Added Arjan in case he as anything to add about the idle=poll below ]
> >
> >
> > On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
> >> On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven
On Thu, Mar 21, 2013 at 10:41:30AM -0700, Arjan van de Ven wrote:
> On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
> > o Use the "idle=poll" boot parameter. However, please note
> > that use of this parameter can cause your CPU to overheat,
> > which may cause
2013/3/21 Steven Rostedt :
> [ Added Arjan in case he as anything to add about the idle=poll below ]
>
>
> On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
>> On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
>> > Not a comment on this document, but on the implementation.
On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
o Use the "idle=poll" boot parameter. However, please note
that use of this parameter can cause your CPU to overheat,
which may cause thermal throttling to degrade your
latencies --and
On Thu, Mar 21, 2013 at 08:45:07AM -0700, Arjan van de Ven wrote:
> On 3/20/2013 5:27 PM, Steven Rostedt wrote:
> >I'm not sure I would recommend idle=poll either. It would certainly
> >work, but it goes to the other extreme. You think NO_HZ=n drains a
> >battery? Try idle=poll.
>
>
> do not
On Thu, Mar 21, 2013 at 04:08:08PM +, Christoph Lameter wrote:
> On Wed, 20 Mar 2013, Paul E. McKenney wrote:
>
> > > > Another approach is to offload RCU callback processing to "rcuo"
> > > > kthreads
> > > > using the CONFIG_RCU_NOCB_CPU=y. The specific CPUs to offload may be
> > > >
On Wed, 20 Mar 2013, Paul E. McKenney wrote:
> > > Another approach is to offload RCU callback processing to "rcuo" kthreads
> > > using the CONFIG_RCU_NOCB_CPU=y. The specific CPUs to offload may be
> > > selected via several methods:
Why are there multiple rcuo threads? Would a single thread
On Thu, Mar 21, 2013 at 08:18:11AM -0700, Paul E. McKenney wrote:
> Actually, this is a generic transformation. Given an English verb,
> you almost always add "ing" to create a noun. Since "round-robin" is
> used as a verb,
... which sounds, in this case, weird IMHO. :-)
> as in "The scheduler
On 3/20/2013 5:27 PM, Steven Rostedt wrote:
I'm not sure I would recommend idle=poll either. It would certainly
work, but it goes to the other extreme. You think NO_HZ=n drains a
battery? Try idle=poll.
do not ever use idle=poll on anything production.. really bad idea.
if you temporary
On Thu, Mar 21, 2013 at 11:16:50AM +0100, Borislav Petkov wrote:
> On Wed, Mar 20, 2013 at 07:22:59PM -0700, Paul E. McKenney wrote:
> > > > > > The "full_nohz=" boot parameter specifies which CPUs are to be
> > > > > > adaptive-ticks CPUs. For example, "full_nohz=1,6-8" says that CPUs
> > > > >
On Wed, Mar 20, 2013 at 07:22:59PM -0700, Paul E. McKenney wrote:
> > > > > The "full_nohz=" boot parameter specifies which CPUs are to be
> > > > > adaptive-ticks CPUs. For example, "full_nohz=1,6-8" says that CPUs 1,
> > > >
> > > > This is the first time you mention "adaptive-ticks". Probably
On Wed, Mar 20, 2013 at 07:22:59PM -0700, Paul E. McKenney wrote:
The full_nohz= boot parameter specifies which CPUs are to be
adaptive-ticks CPUs. For example, full_nohz=1,6-8 says that CPUs 1,
This is the first time you mention adaptive-ticks. Probably should
define it
On Thu, Mar 21, 2013 at 11:16:50AM +0100, Borislav Petkov wrote:
On Wed, Mar 20, 2013 at 07:22:59PM -0700, Paul E. McKenney wrote:
The full_nohz= boot parameter specifies which CPUs are to be
adaptive-ticks CPUs. For example, full_nohz=1,6-8 says that CPUs
1,
This
On 3/20/2013 5:27 PM, Steven Rostedt wrote:
I'm not sure I would recommend idle=poll either. It would certainly
work, but it goes to the other extreme. You think NO_HZ=n drains a
battery? Try idle=poll.
do not ever use idle=poll on anything production.. really bad idea.
if you temporary
On Thu, Mar 21, 2013 at 08:18:11AM -0700, Paul E. McKenney wrote:
Actually, this is a generic transformation. Given an English verb,
you almost always add ing to create a noun. Since round-robin is
used as a verb,
... which sounds, in this case, weird IMHO. :-)
as in The scheduler will
On Wed, 20 Mar 2013, Paul E. McKenney wrote:
Another approach is to offload RCU callback processing to rcuo kthreads
using the CONFIG_RCU_NOCB_CPU=y. The specific CPUs to offload may be
selected via several methods:
Why are there multiple rcuo threads? Would a single thread that may be
On Thu, Mar 21, 2013 at 04:08:08PM +, Christoph Lameter wrote:
On Wed, 20 Mar 2013, Paul E. McKenney wrote:
Another approach is to offload RCU callback processing to rcuo
kthreads
using the CONFIG_RCU_NOCB_CPU=y. The specific CPUs to offload may be
selected via several
On Thu, Mar 21, 2013 at 08:45:07AM -0700, Arjan van de Ven wrote:
On 3/20/2013 5:27 PM, Steven Rostedt wrote:
I'm not sure I would recommend idle=poll either. It would certainly
work, but it goes to the other extreme. You think NO_HZ=n drains a
battery? Try idle=poll.
do not ever use
On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
o Use the idle=poll boot parameter. However, please note
that use of this parameter can cause your CPU to overheat,
which may cause thermal throttling to degrade your
latencies --and
2013/3/21 Steven Rostedt rost...@goodmis.org:
[ Added Arjan in case he as anything to add about the idle=poll below ]
On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
Not a comment on this document, but on the
On Thu, Mar 21, 2013 at 10:41:30AM -0700, Arjan van de Ven wrote:
On 3/21/2013 10:18 AM, Paul E. McKenney wrote:
o Use the idle=poll boot parameter. However, please note
that use of this parameter can cause your CPU to overheat,
which may cause thermal
On Thu, Mar 21, 2013 at 07:01:01PM +0100, Frederic Weisbecker wrote:
2013/3/21 Steven Rostedt rost...@goodmis.org:
[ Added Arjan in case he as anything to add about the idle=poll below ]
On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
On Wed, Mar 20, 2013 at 07:32:18PM -0400,
On Thu, 2013-03-21 at 10:15 -0700, Paul E. McKenney wrote:
The OS always has some sched other tasks around that become runnable after
a while (like for example the vm statistics update, or the notorious slab
scanning). As long as SCHED_FIFO is active and there is no process in the
same
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
Why are there multiple rcuo threads? Would a single thread that may be
able to run on multiple cpus not be sufficient?
In many cases, this would indeed be sufficient. However, if you have
enough CPUs posting RCU callbacks, then the single
On Thu, Mar 21, 2013 at 06:39:09PM +, Christoph Lameter wrote:
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
Why are there multiple rcuo threads? Would a single thread that may be
able to run on multiple cpus not be sufficient?
In many cases, this would indeed be sufficient.
On Thu, Mar 21, 2013 at 02:44:22PM -0400, Steven Rostedt wrote:
On Thu, 2013-03-21 at 10:15 -0700, Paul E. McKenney wrote:
The OS always has some sched other tasks around that become runnable after
a while (like for example the vm statistics update, or the notorious slab
scanning). As
On Thu, 21 Mar 2013, Steven Rostedt wrote:
For now, no, if more than one process is scheduled on the CPU, we fall
out of dynamic tick mode. In the future, we can add SCHED_FIFO task
scheduled in to trigger it. But lets conquer that after we successfully
conquer the current changes.
Be glad
On Thu, 2013-03-21 at 18:53 +, Christoph Lameter wrote:
On Thu, 21 Mar 2013, Steven Rostedt wrote:
For now, no, if more than one process is scheduled on the CPU, we fall
out of dynamic tick mode. In the future, we can add SCHED_FIFO task
scheduled in to trigger it. But lets conquer
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
Yeah doing that right now but I'd like to see it handled without manual
intervention.
Given that RCU has no idea where you want them to run, some manual
intervention would most likely be required even if RCU spawned them
dynamically, right?
If
2013/3/21 Christoph Lameter c...@linux.com:
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
So, again, removing scheduling-clock interrupts in more situations is
a good future enhancement.
The point here is that the check for a single runnable process is wrong
because it accounts for tasks in
On Thu, Mar 21, 2013 at 08:04:08PM +, Christoph Lameter wrote:
On Thu, 21 Mar 2013, Paul E. McKenney wrote:
Yeah doing that right now but I'd like to see it handled without manual
intervention.
Given that RCU has no idea where you want them to run, some manual
intervention would
On Thu, 21 Mar 2013, Frederic Weisbecker wrote:
Sure, for now just don't use SCHED_FIFO and you will have a much more
extended dynticks coverage.
Ah. Ok. Important information. That would mean no tick for the 2 second
intervals between the vm stats etc. Much much better than now where we
have
2013/3/21 Christoph Lameter c...@linux.com:
On Thu, 21 Mar 2013, Frederic Weisbecker wrote:
Sure, for now just don't use SCHED_FIFO and you will have a much more
extended dynticks coverage.
Ah. Ok. Important information. That would mean no tick for the 2 second
intervals between the vm
On 03/21/2013 10:45:07 AM, Arjan van de Ven wrote:
On 3/20/2013 5:27 PM, Steven Rostedt wrote:
I'm not sure I would recommend idle=poll either. It would certainly
work, but it goes to the other extreme. You think NO_HZ=n drains a
battery? Try idle=poll.
do not ever use idle=poll on anything
On Wed, Mar 20, 2013 at 08:27:11PM -0400, Steven Rostedt wrote:
> [ Added Arjan in case he as anything to add about the idle=poll below ]
Good point!
> On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
> > On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
> > > On Mon,
[ Added Arjan in case he as anything to add about the idle=poll below ]
On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
> On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
> > On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKenney wrote:
> >
> > >
On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
> On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKenney wrote:
>
> >
> >
> > NO_HZ: Reducing Scheduling-Clock Ticks
> >
> >
> > This document
On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKenney wrote:
>
>
> NO_HZ: Reducing Scheduling-Clock Ticks
>
>
> This document covers Kconfig options and boot parameters used to reduce
> the number of
On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKenney wrote:
NO_HZ: Reducing Scheduling-Clock Ticks
This document covers Kconfig options and boot parameters used to reduce
the number of scheduling-clock
On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKenney wrote:
NO_HZ: Reducing Scheduling-Clock Ticks
This document covers Kconfig
[ Added Arjan in case he as anything to add about the idle=poll below ]
On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
On Mon, 2013-03-18 at 15:25 -0700, Paul E. McKenney wrote:
On Wed, Mar 20, 2013 at 08:27:11PM -0400, Steven Rostedt wrote:
[ Added Arjan in case he as anything to add about the idle=poll below ]
Good point!
On Wed, 2013-03-20 at 16:55 -0700, Paul E. McKenney wrote:
On Wed, Mar 20, 2013 at 07:32:18PM -0400, Steven Rostedt wrote:
On Mon, 2013-03-18
On Mon, Mar 18, 2013 at 09:48:31PM +0100, Frederic Weisbecker wrote:
> 2013/3/18 Rob Landley :
> > On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
[ . . . ]
> >> >> +o At least one CPU must keep the scheduling-clock interrupt going
> >> >> + in order to support accurate
2013/3/18 Rob Landley :
> On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
>> I really think we want to keep all the detailed explanations from
>> Paul's doc. What we need is not a quick reference but a very detailed
>> documentation.
>
>
> It's much _longer_, I'm not sure it contains
On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
2013/3/18 Rob Landley :
> On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
> And really seems like it's kconfig help text?
It's more exhaustive than a Kconfig help. A Kconfig help text should
have the level of detail that describe the
2013/3/18 Rob Landley :
> On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
> And really seems like it's kconfig help text?
It's more exhaustive than a Kconfig help. A Kconfig help text should
have the level of detail that describe the purpose and impact of a
feature, as well as some quick
On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
First attempt at documentation for adaptive ticks.
Thoughts?
Thanx, Paul
It's really long and repetitive? And really seems like it's kconfig
help text?
The CONFIG_NO_HZ=y and
First attempt at documentation for adaptive ticks.
Thoughts?
Thanx, Paul
nohz1: Documentation
Signed-off-by: Paul E. McKenney
diff --git
First attempt at documentation for adaptive ticks.
Thoughts?
Thanx, Paul
nohz1: Documentation
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
diff --git
On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
First attempt at documentation for adaptive ticks.
Thoughts?
Thanx, Paul
It's really long and repetitive? And really seems like it's kconfig
help text?
The CONFIG_NO_HZ=y and
2013/3/18 Rob Landley r...@landley.net:
On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
And really seems like it's kconfig help text?
It's more exhaustive than a Kconfig help. A Kconfig help text should
have the level of detail that describe the purpose and impact of a
feature, as well as
On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
2013/3/18 Rob Landley r...@landley.net:
On 03/18/2013 11:29:42 AM, Paul E. McKenney wrote:
And really seems like it's kconfig help text?
It's more exhaustive than a Kconfig help. A Kconfig help text should
have the level of detail that
2013/3/18 Rob Landley r...@landley.net:
On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
I really think we want to keep all the detailed explanations from
Paul's doc. What we need is not a quick reference but a very detailed
documentation.
It's much _longer_, I'm not sure it contains
On Mon, Mar 18, 2013 at 09:48:31PM +0100, Frederic Weisbecker wrote:
2013/3/18 Rob Landley r...@landley.net:
On 03/18/2013 01:46:32 PM, Frederic Weisbecker wrote:
[ . . . ]
+o At least one CPU must keep the scheduling-clock interrupt going
+ in order to support accurate
86 matches
Mail list logo
