linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Archs <linux-arch@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Rik van Riel <riel@redhat.com>, Huiqingding <huding@redhat.com>
Subject: Re: [GIT PULL v2] timers updates for 3.15
Date: Thu, 13 Mar 2014 16:33:04 +0100	[thread overview]
Message-ID: <20140313153301.GA25296@localhost.localdomain> (raw)
In-Reply-To: <20140313110510.GA10424@gmail.com>

On Thu, Mar 13, 2014 at 12:05:10PM +0100, Ingo Molnar wrote:
> 
> * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 
> > Ingo, Thomas,
> > 
> > Please pull the timers/cputime-fix-steal-v3 branch that can be found at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > 	timers/cputime-fix-steal-v3
> > 
> > Only the last patch changed to address Peterz concern on arch Kbuild
> > layout. This got sorted out by running the script from b119fa61d440f
> > to alpabetically sort the entries.
> > 
> > ---
> > The main purpose of this set is to fix a bug on full dynticks configs
> > where steal time accounting appears to be zero in /proc/stat even
> > after a few seconds of competing guests running busy loops in a same
> > host CPU. It's not a regression though as it was there since the
> > beginning with full dynticks.
> > 
> > So patch [4/6] ("cputime: Fix jiffies based cputime assumption on
> > steal accounting") is the most important patch of the series. The rest
> > is mostly preparatory work to fix the bug plus various cleanups.
> > 
> > Thanks,
> > 	Frederic
> > ---
> > 
> > Frederic Weisbecker (6):
> >       cputime: Fix nsecs_to_cputime() return type cast
> >       cputime: Default implementation of nsecs -> cputime conversion
> >       cputime: Bring cputime -> nsecs conversion
> >       cputime: Fix jiffies based cputime assumption on steal accounting
> >       sched: Remove needless round trip nsecs <-> tick conversion of steal time
> >       arch: Remove stub cputime.h headers
> > 
> > 
> >  arch/alpha/include/asm/Kbuild         |  7 ++++---
> >  arch/alpha/include/asm/cputime.h      |  6 ------
> >  arch/cris/include/asm/Kbuild          |  3 ++-
> >  arch/cris/include/asm/cputime.h       |  6 ------
> >  arch/frv/include/asm/Kbuild           |  5 +++--
> >  arch/frv/include/asm/cputime.h        |  6 ------
> >  arch/m32r/include/asm/Kbuild          |  5 +++--
> >  arch/m32r/include/asm/cputime.h       |  6 ------
> >  arch/microblaze/include/asm/Kbuild    |  5 +++--
> >  arch/microblaze/include/asm/cputime.h |  1 -
> >  arch/mn10300/include/asm/Kbuild       |  3 ++-
> >  arch/mn10300/include/asm/cputime.h    |  1 -
> >  arch/score/include/asm/Kbuild         |  4 ++--
> >  arch/score/include/asm/cputime.h      |  6 ------
> >  arch/x86/include/asm/Kbuild           |  1 +
> >  arch/x86/include/asm/cputime.h        |  1 -
> 
> Does this tree also address the heavy conflicts with tip:core/locking? 

Ah I didn't hear about that. Thomas told me there was a conflict issue but
he couldn't tell me more about it.

> If not then we should probably carry this in a separate branch that 
> merges tip:core/locking and tip:timers/core.

So I propose you something even more simple. The choice of tip:timers/core
as a base was actually just about topic. But there is no dependency on it.
(And actually sched/core would have been a better choice for a base if any).

So in order to fix the conflict and minimize the dependencies, I just
rebased the patches on top of tip:core/locking only. No merge on top of that.
It seems to work pretty well.

The pullable result is in sched/cputime on my tree. Let me know if that's ok
for you.

Thanks.

  reply	other threads:[~2014-03-13 15:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 16:36 [GIT PULL v2] timers updates for 3.15 Frederic Weisbecker
2014-03-12 16:36 ` Frederic Weisbecker
2014-03-13 11:05 ` Ingo Molnar
2014-03-13 15:33   ` Frederic Weisbecker [this message]
2014-03-14  8:36     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140313153301.GA25296@localhost.localdomain \
    --to=fweisbec@gmail.com \
    --cc=huding@redhat.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).