Re: [PATCH 0/2] sched/cputime: Deltas for "replace VTIME_GEN irq time code with IRQ_TIME_ACCOUNTING code"

From: Frederic Weisbecker
Date: Fri Jul 08 2016 - 08:05:27 EST


On Fri, Jul 08, 2016 at 02:03:03PM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
>
> > On Fri, Jul 08, 2016 at 09:30:46AM +0200, Ingo Molnar wrote:
> > >
> > > * Rik van Riel <riel@xxxxxxxxxx> wrote:
> > >
> > > > On Thu, 2016-07-07 at 16:27 +0200, Frederic Weisbecker wrote:
> > > > > Hi Rick,
> > > > >
> > > > > While reviewing your 2nd patch, I thought about these cleanups.
> > > > > Perhaps
> > > > > the first one could be merged into your patch. I let you decide.
> > > >
> > > > I'm not convinced we want to merge cleanups and functional
> > > > changes into the same patch, given how convoluted the code
> > > > is/was.
> > > >
> > > > Both of your patches look good though.
> > > >
> > > > What tree should they go in through?
> > >
> > > -tip I suspect. So my plan was the following, this series of yours:
> > >
> > > [PATCH v3 0/4] sched,time: fix irq time accounting with nohz_idle
> > >
> > > ... looked almost ready, it looked like as if I could merge v4 once you sent it.
> > >
> > > Plus Frederic submitted these two cleanups - looks like I could merge these on top
> > > of your series and have them close to each other in the Git space.
> > >
> > > And I do agree that we should keep these cleanups separate and not merge them into
> > > patches that change functionality.
> > >
> > > If your series is expected to be risky then we could make things easier to handle
> > > later on if we switched around things and first made low-risk cleanups and then
> > > any changes/fixes on top - do you think that's necessary in this case?
> >
> > I personally think that none of this is low-risk material. Perhaps we can gather
> > the whole in the same tree? I can resend the series proper with my patches
> > inside if you like. And I have yet to review the last patch of the series.
>
> Sure, we can do it like that, for tip:timers/nohz.

Ok, I'll base it on tip:sched/core, right?