lkml.org 
[lkml]   [2009]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:timers/core] timekeeping: Increase granularity of read_persistent_clock()

* Paul Mackerras <paulus@samba.org> wrote:

> Ingo Molnar writes:
>
> > * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> > > I overlooked a case in the powerpc version of read_persistent_lock.
> > > New patch:
> >
> > the patches are already committed and this patch doesnt apply -
> > mind sending a delta fix against tip:master:
>
> Is that going to leave us with a bisection breakage on powerpc
> once this stuff goes upstream? If so please fold the fix into the
> original patch.

Do you ask Linus to rebase the upstream kernel as well, if the
powerpc or x86 build happens to break? There's more than a dozen
such cases per development cycle triggering on my tests alone. If
not, why not?

The thing is, we'll probably redo this portion of the timer tree as
i found other problems in testing, but generally the disadvantages
of a build breakage with a very small non-bisectability window has
to be weighed against the disadvantages of a rebase (which are
significant).

The equation does not automatically flip in favor of a rebase as you
seem to suggest - in fact it generally goes _against_ a rebase.

Ingo


\
 
 \ /
  Last update: 2009-08-23 10:55    [W:2.248 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site