Messages in this thread | | | Date | Sun, 23 Aug 2009 10:47:40 +0200 | From | Ingo Molnar <> | Subject | Re: [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
| |