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
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 timer_list
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 offe
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?
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 th
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 defin
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
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 p
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 etc.
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
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
> > inter
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 sche
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, rig
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 con
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 gla
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
> > > scan
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 suffici
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, 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 the
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. As
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 th
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
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
> > > > selec
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 t
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 wi
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 canno
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 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
[ 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 covers
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
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 timekeepi
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 signific
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 purpo
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 refere
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 CONFIG_N
First attempt at documentation for adaptive ticks.
Thoughts?
Thanx, Paul
nohz1: Documentation
Signed-off-by: Paul E. McKenney
diff --git a/Documentation/timers/NO_
43 matches
Mail list logo
