On Thu, 8 May 2014, Andrew Morton wrote:
> Some explanation of the changes to kernel/time/tick-common.c would be
> appropriate.
I dropped those after the discussion related to housekeepig cpus.
> > + cancel_delayed_work_sync(d);
> > + cpumask_set_cpu(smp_processor_id(),
On Thu, 8 May 2014, Andrew Morton wrote:
Some explanation of the changes to kernel/time/tick-common.c would be
appropriate.
I dropped those after the discussion related to housekeepig cpus.
+ cancel_delayed_work_sync(d);
+ cpumask_set_cpu(smp_processor_id(),
On Sun, May 11, 2014 at 03:30:31AM +0200, Frederic Weisbecker wrote:
> On Sat, May 10, 2014 at 06:17:08PM -0700, Paul E. McKenney wrote:
> > On Sat, May 10, 2014 at 03:14:25PM +0200, Frederic Weisbecker wrote:
> > > On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
> > > > On Sat,
On Sat, May 10, 2014 at 06:17:08PM -0700, Paul E. McKenney wrote:
> On Sat, May 10, 2014 at 03:14:25PM +0200, Frederic Weisbecker wrote:
> > On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
> > > On Sat, 10 May 2014, Frederic Weisbecker wrote:
> > > > But I still have the plan to
On Sat, May 10, 2014 at 03:14:25PM +0200, Frederic Weisbecker wrote:
> On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
> > On Sat, 10 May 2014, Frederic Weisbecker wrote:
> > > But I still have the plan to make the timekeeper use the full sysidle
> > > facility in order to
On Sat, May 10, 2014 at 02:34:49AM +0200, Frederic Weisbecker wrote:
[ . . . ]
> So the "only" damage is on bad directions given to Christoph. But you know
> how I use GPS...
Well, my redundant ACCESS_ONCE() around tick_do_timer_cpu was also
quite misleading... :-/
On Sat, May 10, 2014 at 02:20:36PM +0200, Thomas Gleixner wrote:
> On Fri, 9 May 2014, Paul E. McKenney wrote:
>
> > On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
> > > On Fri, 9 May 2014, Christoph Lameter wrote:
> > > > On Fri, 9 May 2014, Thomas Gleixner wrote:
> > > > > I
On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
> On Sat, 10 May 2014, Frederic Weisbecker wrote:
> > But I still have the plan to make the timekeeper use the full sysidle
> > facility in order to adaptively get to dynticks idle.
> >
> > Reminder for others: in NO_HZ_FULL, the
On Sat, 10 May 2014, Frederic Weisbecker wrote:
> But I still have the plan to make the timekeeper use the full sysidle
> facility in order to adaptively get to dynticks idle.
>
> Reminder for others: in NO_HZ_FULL, the timekeeper (always CPU 0) stays
> completely periodic. It can't enter in
On Sat, 10 May 2014, Frederic Weisbecker wrote:
> Anyway I agree that was overengineering at this stage.
>
> Fortunately nothing has been applied. I was too busy with cleanups and
> workqueues
> affinity.
Good.
> So the "only" damage is on bad directions given to Christoph. But you know
> how
On Fri, 9 May 2014, Paul E. McKenney wrote:
> On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
> > On Fri, 9 May 2014, Christoph Lameter wrote:
> > > On Fri, 9 May 2014, Thomas Gleixner wrote:
> > > > I understand why you want to get this done by a housekeeper, I just
> > > > did
On Fri, 9 May 2014, Paul E. McKenney wrote:
On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
On Fri, 9 May 2014, Christoph Lameter wrote:
On Fri, 9 May 2014, Thomas Gleixner wrote:
I understand why you want to get this done by a housekeeper, I just
did not understand
On Sat, 10 May 2014, Frederic Weisbecker wrote:
Anyway I agree that was overengineering at this stage.
Fortunately nothing has been applied. I was too busy with cleanups and
workqueues
affinity.
Good.
So the only damage is on bad directions given to Christoph. But you know
how I use
On Sat, 10 May 2014, Frederic Weisbecker wrote:
But I still have the plan to make the timekeeper use the full sysidle
facility in order to adaptively get to dynticks idle.
Reminder for others: in NO_HZ_FULL, the timekeeper (always CPU 0) stays
completely periodic. It can't enter in dynticks
On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
On Sat, 10 May 2014, Frederic Weisbecker wrote:
But I still have the plan to make the timekeeper use the full sysidle
facility in order to adaptively get to dynticks idle.
Reminder for others: in NO_HZ_FULL, the timekeeper
On Sat, May 10, 2014 at 02:20:36PM +0200, Thomas Gleixner wrote:
On Fri, 9 May 2014, Paul E. McKenney wrote:
On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
On Fri, 9 May 2014, Christoph Lameter wrote:
On Fri, 9 May 2014, Thomas Gleixner wrote:
I understand why
On Sat, May 10, 2014 at 02:34:49AM +0200, Frederic Weisbecker wrote:
[ . . . ]
So the only damage is on bad directions given to Christoph. But you know
how I use GPS...
Well, my redundant ACCESS_ONCE() around tick_do_timer_cpu was also
quite misleading... :-/
On Sat, May 10, 2014 at 03:14:25PM +0200, Frederic Weisbecker wrote:
On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
On Sat, 10 May 2014, Frederic Weisbecker wrote:
But I still have the plan to make the timekeeper use the full sysidle
facility in order to adaptively get
On Sat, May 10, 2014 at 06:17:08PM -0700, Paul E. McKenney wrote:
On Sat, May 10, 2014 at 03:14:25PM +0200, Frederic Weisbecker wrote:
On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
On Sat, 10 May 2014, Frederic Weisbecker wrote:
But I still have the plan to make the
On Sun, May 11, 2014 at 03:30:31AM +0200, Frederic Weisbecker wrote:
On Sat, May 10, 2014 at 06:17:08PM -0700, Paul E. McKenney wrote:
On Sat, May 10, 2014 at 03:14:25PM +0200, Frederic Weisbecker wrote:
On Sat, May 10, 2014 at 02:31:28PM +0200, Thomas Gleixner wrote:
On Sat, 10 May
On Fri, May 09, 2014 at 04:47:45PM -0700, Paul E. McKenney wrote:
> On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
> If someone decides to make tick_do_timer_cpu non-constant in NO_HZ_FULL
> CPUs, they will break unless/until I make RCU deal with that sort
> of thing, at least
On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
> On Fri, 9 May 2014, Christoph Lameter wrote:
> > On Fri, 9 May 2014, Thomas Gleixner wrote:
> > > I understand why you want to get this done by a housekeeper, I just
> > > did not understand why we need this whole move it around
On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
> On Fri, 9 May 2014, Christoph Lameter wrote:
> > On Fri, 9 May 2014, Thomas Gleixner wrote:
> > > I understand why you want to get this done by a housekeeper, I just
> > > did not understand why we need this whole move it around
On Fri, 9 May 2014, Christoph Lameter wrote:
> On Fri, 9 May 2014, Thomas Gleixner wrote:
> > I understand why you want to get this done by a housekeeper, I just
> > did not understand why we need this whole move it around business is
> > required.
>
> This came about because of another objection
On Fri, 9 May 2014, Thomas Gleixner wrote:
> > Ok how do I figure out that cpu? I'd rather have a specific cpu that
> > never changes.
>
> I followed the full nohz development only losely, but back then when
> all started here at my place with frederic, we had a way to define the
> housekeeper
On Fri, 9 May 2014, Christoph Lameter wrote:
> On Fri, 9 May 2014, Thomas Gleixner wrote:
> > I think we agreed long ago, that for the whole HPC FULL_NOHZ stuff you
> > have to sacrify at least one CPU for housekeeping purposes of all
> > kinds, timekeeping, statistics and whatever.
>
> Ok how do
On Fri, 9 May 2014, Thomas Gleixner wrote:
> > > +/*
> > > + * Return a cpu number that may be used to run housekeeping
> > > + * tasks. This is usually the timekeeping cpu unless that
> > > + * is not available. Then we simply fall back to the current
> > > + * cpu.
> > > + */
> >
> > This
On Fri, 9 May 2014, Thomas Gleixner wrote:
+/*
+ * Return a cpu number that may be used to run housekeeping
+ * tasks. This is usually the timekeeping cpu unless that
+ * is not available. Then we simply fall back to the current
+ * cpu.
+ */
This comment is unusably vague.
On Fri, 9 May 2014, Christoph Lameter wrote:
On Fri, 9 May 2014, Thomas Gleixner wrote:
I think we agreed long ago, that for the whole HPC FULL_NOHZ stuff you
have to sacrify at least one CPU for housekeeping purposes of all
kinds, timekeeping, statistics and whatever.
Ok how do I figure
On Fri, 9 May 2014, Thomas Gleixner wrote:
Ok how do I figure out that cpu? I'd rather have a specific cpu that
never changes.
I followed the full nohz development only losely, but back then when
all started here at my place with frederic, we had a way to define the
housekeeper cpu. I
On Fri, 9 May 2014, Christoph Lameter wrote:
On Fri, 9 May 2014, Thomas Gleixner wrote:
I understand why you want to get this done by a housekeeper, I just
did not understand why we need this whole move it around business is
required.
This came about because of another objection against
On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
On Fri, 9 May 2014, Christoph Lameter wrote:
On Fri, 9 May 2014, Thomas Gleixner wrote:
I understand why you want to get this done by a housekeeper, I just
did not understand why we need this whole move it around business is
On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
On Fri, 9 May 2014, Christoph Lameter wrote:
On Fri, 9 May 2014, Thomas Gleixner wrote:
I understand why you want to get this done by a housekeeper, I just
did not understand why we need this whole move it around business is
On Fri, May 09, 2014 at 04:47:45PM -0700, Paul E. McKenney wrote:
On Sat, May 10, 2014 at 12:57:15AM +0200, Thomas Gleixner wrote:
If someone decides to make tick_do_timer_cpu non-constant in NO_HZ_FULL
CPUs, they will break unless/until I make RCU deal with that sort
of thing, at least for
On Thu, 8 May 2014, Andrew Morton wrote:
> On Thu, 8 May 2014 10:35:15 -0500 (CDT) Christoph Lameter
> wrote:
> > --- linux.orig/kernel/time/tick-common.c2014-05-06 10:51:19.711239813
> > -0500
> > +++ linux/kernel/time/tick-common.c 2014-05-06 10:51:19.711239813 -0500
> > @@ -222,6 +222,24
(tglx poke)
On Thu, 8 May 2014 10:35:15 -0500 (CDT) Christoph Lameter
wrote:
> There were numerous requests for an update of this patch.
>
>
> V3->V4:
> - Make the shepherd task not deferrable. It runs on the tick cpu
> anyways. Deferral could get deltas too far out of sync if
> vmstat
There were numerous requests for an update of this patch.
V3->V4:
- Make the shepherd task not deferrable. It runs on the tick cpu
anyways. Deferral could get deltas too far out of sync if
vmstat operations are disabled for a certain processor.
V2->V3:
- Introduce a new
There were numerous requests for an update of this patch.
V3-V4:
- Make the shepherd task not deferrable. It runs on the tick cpu
anyways. Deferral could get deltas too far out of sync if
vmstat operations are disabled for a certain processor.
V2-V3:
- Introduce a new
(tglx poke)
On Thu, 8 May 2014 10:35:15 -0500 (CDT) Christoph Lameter c...@linux.com
wrote:
There were numerous requests for an update of this patch.
V3-V4:
- Make the shepherd task not deferrable. It runs on the tick cpu
anyways. Deferral could get deltas too far out of sync if
On Thu, 8 May 2014, Andrew Morton wrote:
On Thu, 8 May 2014 10:35:15 -0500 (CDT) Christoph Lameter c...@linux.com
wrote:
--- linux.orig/kernel/time/tick-common.c2014-05-06 10:51:19.711239813
-0500
+++ linux/kernel/time/tick-common.c 2014-05-06 10:51:19.711239813 -0500
@@ -222,6
40 matches
Mail list logo
