[GIT pull] x86 fixes for 2.6.26

[GIT pull] x86 fixes for 2.6.26

[Thomas Gleixner]

Linus, 

please pull the latest x86 fixes from:

   ssh://master.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus

Thanks,

	tglx

------------------>
Avi Kivity (1):
      x86: fix crash on cpu hotplug on pat-incapable machines

Ingo Molnar (1):
      x86: remove mwait capability C-state check

Thomas Gleixner (1):
      x86: disable mwait for AMD family 10H/11H CPUs

 arch/x86/kernel/process.c |   36 +++++++++++++++++++++++++++---------
 arch/x86/mm/pat.c         |    2 +-
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 67e9b4a..ba370dc 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -99,15 +99,6 @@ static void mwait_idle(void)
 		local_irq_enable();
 }
 
-
-static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
-{
-	if (force_mwait)
-		return 1;
-	/* Any C1 states supported? */
-	return c->cpuid_level >= 5 && ((cpuid_edx(5) >> 4) & 0xf) > 0;
-}
-
 /*
  * On SMP it's slightly faster (but much more power-consuming!)
  * to poll the ->work.need_resched flag instead of waiting for the
@@ -119,6 +110,33 @@ static void poll_idle(void)
 	cpu_relax();
 }
 
+/*
+ * mwait selection logic:
+ *
+ * It depends on the CPU. For AMD CPUs that support MWAIT this is
+ * wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings
+ * then depend on a clock divisor and current Pstate of the core. If
+ * all cores of a processor are in halt state (C1) the processor can
+ * enter the C1E (C1 enhanced) state. If mwait is used this will never
+ * happen.
+ *
+ * idle=mwait overrides this decision and forces the usage of mwait.
+ */
+static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
+{
+	if (force_mwait)
+		return 1;
+
+	if (c->x86_vendor == X86_VENDOR_AMD) {
+		switch(c->x86) {
+		case 0x10:
+		case 0x11:
+			return 0;
+		}
+	}
+	return 1;
+}
+
 void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	static int selected;
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index bcb1a8e..de3a998 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -28,7 +28,7 @@
 #ifdef CONFIG_X86_PAT
 int __read_mostly pat_wc_enabled = 1;
 
-void __init pat_disable(char *reason)
+void __cpuinit pat_disable(char *reason)
 {
 	pat_wc_enabled = 0;
 	printk(KERN_INFO "%s\n", reason);

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Sat, 17 May 2008, Thomas Gleixner wrote:
> 
> please pull the latest x86 fixes from:
> 
>    ssh://master.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus

No.

You have three real commits there.

And *six* unnecessary merges.

Why do you merge my tree? Is it the x86 tree, or is it the "general 
development tree"?

If it's the x86 tree, it shouldn't need to merge everythign else all the 
time. Certainly not if it means that moer than half the commits are just 
merges.

Do nice topic branches, where each branch has a reason for existing. The 
"x86-fixes-for-linus" branch has x86 fixes. 

This happens almost every time somebody starts using git properly: at that 
point the rebasing no longer hides bad habits.

		Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Fri, 16 May 2008, Linus Torvalds wrote:
> 
> This happens almost every time somebody starts using git properly: at that 
> point the rebasing no longer hides bad habits.

Side note: to see this in action, just do

	gitk linus..

on that branch tip. Or look at the shortlog output without --no-merges:

	Avi Kivity (1):
	      x86: fix crash on cpu hotplug on pat-incapable machines

	Ingo Molnar (6):
	      Merge branch 'linus' into x86/urgent
	      Merge branch 'linus' into x86/urgent
	      Merge branch 'linus' into x86/urgent
	      Merge branch 'x86/urgent' of e2:tip into x86/urgent
	      x86: remove mwait capability C-state check
	      Merge branch 'linus' into x86/urgent

	Thomas Gleixner (1):
	      x86: disable mwait for AMD family 10H/11H CPUs

where those five merges (I know, I said six, I can't count, sue me) don't 
actually seem to do anything useful as far as x86 is concerned, ie they 
have nothing to do with the work that you were actually doing.

			Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Thomas Gleixner]

On Fri, 16 May 2008, Linus Torvalds wrote:
> On Sat, 17 May 2008, Thomas Gleixner wrote:
> > 
> > please pull the latest x86 fixes from:
> > 
> >    ssh://master.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus
> 
> No.
> 
> You have three real commits there.
> 
> And *six* unnecessary merges.

Hmm, I saw that coming :)

> Why do you merge my tree? Is it the x86 tree, or is it the "general 
> development tree"?
> 
> If it's the x86 tree, it shouldn't need to merge everythign else all the 
> time. Certainly not if it means that moer than half the commits are just 
> merges.
> 
> Do nice topic branches, where each branch has a reason for existing. The 
> "x86-fixes-for-linus" branch has x86 fixes. 

We have topic branches. How should we keep those topic branches up
to date ? By rebasing ?
 
> This happens almost every time somebody starts using git properly: at that 
> point the rebasing no longer hides bad habits.

We did not rebase at all. All we did is keeping the branches up to
date vs. your tree, which introduces merges whether we want or
not. I'm well aware of the merge commit issue, but I have no real good
idea how to avoid rebasing in order to keep the history intact and
avoid the merge commits at the same time.

Thanks,
	tglx



    

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Sat, 17 May 2008, Thomas Gleixner wrote:
> 
> We have topic branches. How should we keep those topic branches up
> to date ? By rebasing ?

Listen to yourself. They are "topic" branches. They are supposed to do one 
thing. You keep them "uptodate" by doing your work on them, _not_ by 
merging everybody elses work into them.

> > This happens almost every time somebody starts using git properly: at that 
> > point the rebasing no longer hides bad habits.
> 
> We did not rebase at all.

You _used_ to rebase. That hides bad workflows, because it hides the fact 
that your "topic branch" is not a topic branch at all, but something that 
tries to do much more than it's stated purpose.

So now, when you stopped rebasing, the fact that you keep updating your 
topic branches with code that has nothing to do with your topic (ie code 
that I randomly merged from me) is visible as the unnecessary merges.

Yes, doing a merge occasionally just to not fell *too* far behind is sane. 
But when you have twice as many merges as you have real commits, you're 
doing something wrong. At that point, you're no longer a topic branch, 
you're just a mess of other peoples development merged on top of random 
commits you do.

See the difference? You literally merged four times in two days. That's 
not "keeping reasonably up-to-date", that's just messy and OCD.

		Linus

Re: [GIT pull] x86 fixes for 2.6.26

[David Miller]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Fri, 16 May 2008 17:03:37 -0700 (PDT)

> See the difference? You literally merged four times in two days. That's 
> not "keeping reasonably up-to-date", that's just messy and OCD.

Have a look at my networking tree if you want to see an example of how
to handle things Thomas.

I think I merged from Linus's tree only 3 or 4 times maximum since I
created that tree way back when the 2.6.26 merge window opened up.

If users, or even you, want to get a bug fix from Linus's tree or check
if there will be merge conflicts, just create a test branch and play
with such things there.

The topic branch or topic tree should just keep developing,
essentially living in it's own world oblivious to what is going on
upstream.  And it should stay this way until an unavoidable merge
conflict needs to be resolved or things become uncomfortably out of
sync.

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Fri, 16 May 2008, David Miller wrote:
> 
> I think I merged from Linus's tree only 3 or 4 times maximum since I
> created that tree way back when the 2.6.26 merge window opened up.

Basically, a rule-of-thumb would be "once a week is reasonable", but on 
the other hand, if you have actual conflicts, more often is fine, and if 
you know your area isn't impacted (eg most filesystems), you'd probably 
only try to synchronize at release points or something like that.

The reason to avoid doing overly many merges is

 - merging with me at random points is usually not a good idea anyway, 
   unless you have a really strong reason for it. Yes, my tree is fairly 
   stable, but still..

   (This also implies that merging with my *tags* is usually a better idea 
   than merging with some random point in time, and is one reason it makes 
   sense to try to merge with major releases rather than anything else)

 - the history just looks cleaner and is easier to follow when there 
   aren't criss-crossing merges.

   This may not matter most of the time, but it *does* make a difference 
   when doing "git bisect". I don't know about others, but I often do "git 
   bisect visualize" then I have some totally unknown bug and I'm trying 
   to guess what's going on - it's a great way to give people a heads up 
   saying "ok, I'm in the middle of a bisection run, and it _looks_ like 
   it may be due to you".

So trying to have fairly clean history is worth it (it also makes it 
slightly faster to bisect when you don't have lots of criss-cross merges, 
but that's a fairly small factor).

> If users, or even you, want to get a bug fix from Linus's tree or check
> if there will be merge conflicts, just create a test branch and play
> with such things there.

Yes. I think you guys already have a test branch for the "join it all 
together" case, don't you?

		Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Theodore Tso]

On Fri, May 16, 2008 at 03:47:53PM -0700, Linus Torvalds wrote:
> Do nice topic branches, where each branch has a reason for existing. The 
> "x86-fixes-for-linus" branch has x86 fixes. 
> 
> This happens almost every time somebody starts using git properly: at that 
> point the rebasing no longer hides bad habits.

Why do you consider rebasing topic branches a bad thing?  It does help
keep the history much cleaner, and it means that I can test to make
sure the topic branch works well with the latest head of the
development branch.

Is there a write up of what you consider the "proper" git workflow?

   	   	       	    		     	      - Ted

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Fri, 16 May 2008, Theodore Tso wrote:
> 
> Why do you consider rebasing topic branches a bad thing?

Rebasing branches is absolutely not a bad thing for individual developers.

But it *is* a bad thing for a subsystem maintainer.

So I would heartily recommend that if you're a "random developer" and 
you're never going to have anybody really pull from you and you 
*definitely* don't want to pull from other peoples (except the ones that 
you consider to be "strictly upstream" from you!), then you should often 
plan on keeping your own set of patches as a nice linear regression.

And the best way to do that is very much by rebasing them.

That is, for example, what I do myself with all my git patches, since in 
git I'm not the maintainer, but instead send out my changes as emails to 
the git mailing list and to Junio.

So for that end-point-developer situation "git rebase" is absolutely the 
right thing to do. You can keep your patches nicely up-to-date and always 
at the top of your history, and basically use git as an efficient 
patch-queue manager that remembers *your* patches, while at the same time 
making it possible to efficiently synchronize with a distributed up-stream 
maintainer.

So doing "git fetch + git rebase" is *wonderful* if all you keep track of 
is your own patches, and nobody else ever cares until they get merged into 
somebody elses tree (and quite often, sending the patches by email is a 
common situation for this kind of workflow, rather than actually doing git 
merges at all!)

So I think 'git rebase' has been a great tool, and is absolutely worth 
knowing and using.

*BUT*. And this is a pretty big 'but'.

BUT if you're a subsystem maintainer, and other people are supposed to be 
able to pull from you, and you're supposed to merge other peoples work, 
then rebasing is a *horrible* workflow.

Why?

It's horrible for multiple reasons. The primary one being because nobody 
else can depend on your work any more. It can change at any point in time, 
so nobody but a temporary tree (like your "linux-next release of the day" 
or "-mm of the week" thing) can really pull from you sanely. Because each 
time you do a rebase, you'll pull the rug from under them, and they have 
to re-do everything they did last time they tried to track your work.

But there's a secondary reason, which is more indirect, but despite that 
perhaps even more important, at least in the long run. 

If you are a top-level maintainer or an active subsystem, like Ingo or 
Thomas are, you are a pretty central person. That means that you'd better 
be working on the *assumption* that you personally aren't actually going 
to do most of the actual coding (at least not in the long run), but that 
your work is to try to vet and merge other peoples patches rather than 
primarily to write them yourself.

And that in turn means that you're basically where I am, and where I was 
before BK, and that should tell you something. I think a lot of people 
are a lot happier with how I can take their work these days than they 
were six+ years ago.

So you can either try to drink from the firehose and inevitably be bitched 
about because you're holding something up or not giving something the 
attention it deserves, or you can try to make sure that you can let others 
help you. And you'd better select the "let other people help you", because 
otherwise you _will_ burn out. It's not a matter of "if", but of "when".

Now, this isn't a big issue for some subsystems. If you're working in a 
pretty isolated area, and you get perhaps one or two patches on average 
per day, you can happily basically work like a patch-queue, and then other 
peoples patches aren't actually all that different from your own patches, 
and you can basically just rebase and work everything by emailing patches 
around. Big deal.

But for something like the whole x86 architecture, that's not what te 
situation is. The x86 merge isn't "one or two patches per day". It easily 
gets a thousand commits or more per release. That's a LOT. It's not quite 
as much as the networking layer (counting drivers and general networking 
combined), but it's in that kind of ballpark.

And when you're in that kind of ballpark, you should at least think of 
yourself as being where I was six+ years ago before BK. You should really 
seriously try to make sure that you are *not* the single point of failure, 
and you should plan on doing git merges.

And that absolutely *requires* that you not rebase. If you rebase, the 
people down-stream from you cannot effectively work with your git tree 
directly, and you cannot merge their work and then rebase without SCREWING 
UP their work.

And I realize that the x86 tree doesn't do git merges from other 
sub-maintaines of x86 stuff, and I think that's a problem waiting to 
happen. It's not a problem as long as Ingo and Thomas are on the net every 
single day, 12 hours a day, and respond to everything. But speaking from 
experience, you can try to do that for a decade, but it won't really work.

I've talked to Ingo about this a bit, and I'm personally fairly convinced 
that part of the friction with Ingo has been that micro-management on a 
per-patch level. I should know. I used to do it myself. And I still do it, 
but now I do it only for really "core" stuff. So now I get involved in 
stuff like really core VM locking, or the whole BKL thing, but on the 
whole I try to be the anti-thesis of a micro-manager, and just pull from 
the submaintainers.

It's easier for me, but more importantly, it's actually easier for 
everybody *else*, as long as we can get the right flow working.

Which is why I still spend time on git, but even more so, why I also try 
to spend a fair amount of time on explaining flow issues like this. 
Because I want to try to get people on the same page when it comes to how 
patches flow - because that makes it easier for *everybody* in the end.

[ IOW, from my personal perspective, in the short run the easiest thing to 
  do is always "just pull".

  But in the long run, I want to know I can pull in the future too, and 
  part of that means that I try to explain what I expect from downstream, 
  but part of that also means that I try to push down-stream developers 
  into directions where I think they'll be more productive and less 
  stressed out so that they'll hopefully *be* there in the long run.

  And I think both Ingo and Thomas would be more produtive and less 
  stressed out if they could actually pull from some submaintainers of 
  their own, and try to "spread the load" a bit. It involves them finding 
  the right people they can trust, but it also involves them having a 
  workflow in place that _allows_ those kinds of people to then work with 
  them! ]

> Is there a write up of what you consider the "proper" git workflow?

See above. It really depends on where in the work-flow you are.

And it very much does depend on just how big the flow of patches is. For 
example, during 2.6.24..26, net/ and drivers/net had ~2500 commits. 
arch/x86 and include/asm-x86 had ~1300 commits. Those are both big 
numbers. We're talking a constant stream of work.

But Ted, when you look at fs/ext4, you had what, 67 commits in the 
2.6.24..25 window? That's a whole different ballgame. If you have 67 
commits in a release window of two months, we're talking roughly one a 
day, and you probably didn't have a single real conflict with anybody else 
during that whole release window, did you?

In *that* situation, you don't need to try to stream-line the merging. You 
are better off thinking of them as individual patches, and passing them 
around as emails on the ext4 mailing lists. People won't burn out from 
handling an average of one patch a day, even for long long times. Agreed?

Realistically, not many subsystems really need to try to find 
sub-sub-maintainers. Of the architectures, x86 is the most active one 
*by*far*. That said, I think PowerPC actually has a chain of maintenance 
that is better structured, in that there is more of a network of people 
who have their own areas and they pull from each other. And POWERPC only 
has about half the number commits that x86 has. I bet that lower number of 
commits, coupled with the more spread out maintenance situation makes it 
*much* more relaxed for everybody.

Networking, as mentioned, is about twice the number of patches (in 
aggregate) from x86, but the network layer too has a multi-layer 
maintenance setup, so I suspect that it's actually more relaxed about that 
*bigger* flow of commits than arch/x86 is. Of course, that's fairly 
recent: David had to change how he works, exactly so that the people who 
work with him don't have to jump through hoops in order to synchronize 
with his tree.

In other words, I very heavily would suggest that subsystem maintainers - 
at least of the bigger subsystems, really see themselves as being in the 
same situation I am: rather than doing the work, trying to make it easy 
for *others* to do the work, and then just pulling the result.

		Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Theodore Tso]

On Fri, May 16, 2008 at 08:19:04PM -0700, Linus Torvalds wrote:
> > Why do you consider rebasing topic branches a bad thing?
> 
> Rebasing branches is absolutely not a bad thing for individual developers.
> 
> But it *is* a bad thing for a subsystem maintainer.

Right, but so long as a subsystem maintainer doesn't publish his/her
topic branches, and only sends out patches on their topic branches for
discussion via e-mail, they're fine, right?  They can just rebase up
until the point where the patch goes on a non-'pu' or non-'linux-next'
branch.

Basically, this would be the subsystem maintainer sometimes wearing an
"end-point-developer" hat, and sometimes wearing a "subsystem
maintainer" hat.  So rebasing is fine as long as it's clear that it's
happening on branches which are not meant as a base for
submaintainers.  

I believe Junio does this himself for his own topic branches while
developing git, yes?  And that's probably a good reason for him not
actually *publishing* any of his topic branches, and only the 'pu'
branch, which is well known to be a bad idea for folks to use as a
branch point, since it is constantly getting rebased.

> And I realize that the x86 tree doesn't do git merges from other 
> sub-maintaines of x86 stuff, and I think that's a problem waiting to 
> happen. It's not a problem as long as Ingo and Thomas are on the net every 
> single day, 12 hours a day, and respond to everything. But speaking from 
> experience, you can try to do that for a decade, but it won't really work.
> 
> I've talked to Ingo about this a bit, and I'm personally fairly convinced 
> that part of the friction with Ingo has been that micro-management on a 
> per-patch level. I should know. I used to do it myself. And I still do it, 
> but now I do it only for really "core" stuff. So now I get involved in 
> stuff like really core VM locking, or the whole BKL thing, but on the 
> whole I try to be the anti-thesis of a micro-manager, and just pull from 
> the submaintainers.

Heh, can't really argue with your point here.

							- Ted

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Sat, 17 May 2008, Theodore Tso wrote:
> 
> Right, but so long as a subsystem maintainer doesn't publish his/her
> topic branches, and only sends out patches on their topic branches for
> discussion via e-mail, they're fine, right?

Yes. But then you really cannot work with other people with git.

That's what i was saying - you can use "git rebase" as long as you're a 
"leaf developer" from a git standpoint, and everything you do is just 
emailing patches around. 

And quite frankly, if the x86 maintainer is a "leaf developer", we are 
going to be in trouble in the long run. Unless some other architecture 
comes out an takes away all the users and developers (which obviously 
isn't going to happen).

> Basically, this would be the subsystem maintainer sometimes wearing an
> "end-point-developer" hat, and sometimes wearing a "subsystem
> maintainer" hat.  So rebasing is fine as long as it's clear that it's
> happening on branches which are not meant as a base for
> submaintainers.  

It's not about "not meant as a base". It's about "cannot *possibly* be a 
base". And the difference is that while *you* may not want others to base 
their work off it, are you sure others agree?

And realize that while "git rebase" may be making things easier for the 
person that does the rebase, what it ends up doing for *others* is to take 
away options from them, and making for more work for them.

Again, if there are not enough others to matter, then you _should_ make 
the workflow be around your own personal sandbox. So 'git rebase' makes 
sense then.

Basically, it boils down to whether you're a technical manager or a grunt. 

A grunt should use 'git rebase' to keep his own work in line. A technical 
manager, while he hopefully does some useful work on his own, should 
strive to make _others_ do as much work as possible, and then 'git rebase' 
is the wrong thing, because it will always make it harder for the people 
around you to track your tree and to help you update your tree.

And it's absolutely true that Ingo has been a 'grunt' in many ways. Not 
only does everybody start out that way, but if you ask the question "who 
does the actual work" (as a way to find out who is not a manager, because 
managers by definition are useless bloodsucking parasites), then Ingo 
clearly doesn't look very managerial.

But I definitely think we want Ingo and Thomas to be managers, not grunts. 

Yes, both Ingo and Thomas are the top committers when looked at 
individually. Here's the top five committers since 2.6.24 in arch/x86:

	Ingo Molnar (194):
	Thomas Gleixner (125):
	Glauber de Oliveira Costa (117):
	Roland McGrath (103):
	Glauber Costa (92):
	...

and in that sense they look very much non-managerial. But those ~200 
commits are still just two hundred out of 1900 commits total! We *need* 
managers, not just grunts. And I can well imagine how stressful it is to 
not just do the two hundred commits, but also try to orchestrate the other 
~1700 ones.

			Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > If users, or even you, want to get a bug fix from Linus's tree or 
> > check if there will be merge conflicts, just create a test branch 
> > and play with such things there.
> 
> Yes. I think you guys already have a test branch for the "join it all 
> together" case, don't you?

yep, we have such a branch in -tip that is the integration of all 
currently stable topic branches, and which also embedds misc temporary 
convenience fixes that we pick up for ourselves anyway. It's basically 
the -rt model.

[ Our 'latest' branch is in essence a _daily_ stable release of the
  kernel - stable as far as our own testsystems go and as far as 
  contributor boxes go. (We dont "release" it without having at least 10 
  successful bootups of the tree and we immediate resolve regressions 
  one way or another.) ]

We've now solved the merge-commit pollution problem that you noticed (we 
still are git newbies ;-) and you shouldnt see unnecessary merge commits 
in the future anymore. Holler if you see anything else in -tip that 
looks non-Git-ish ...

We've solved it by still doing the merges (we _need_ the information 
about potential upcoming merge trouble), but we dont commit them to the 
topic branches - we throw them away. We only do a permanent, externally 
visible merge if we (after the fact) detect that a merge was non-trivial 
[because an upstream change interfered with the topic].

We had a couple of rather strong technical reasons to keep the topic 
branches merged on a daily basis:

- Spreading out maintenance and risks: people interested in a particular 
  topic can just pick up a topic branch and _usually_ it should just 
  work and should be fairly recent. We encourage contributors to advance 
  individual topics themselves and [now with the -tip tree] send pull 
  requests against trees with that specific topic branch modified, 
  instead of having to come back to our integration branches all the 
  time.

- Testing: we auto-test each topic branch in isolation - so keeping them
  uptodate against upstream is important.

- Automation of conflict resolution: with 30+ topics we cannot detect 
  interactions manually in a reliable way, we detect them automatically. 
  We deal with popular, high-flux areas of the kernel where we often get 
  "outside" interference and where we in fact _encourage_ outside 
  interference (even if we could ask for strict maintenance boundaries) 
  because we dont think strict maintenance boundaries are particularly 
  good for Linux. Other subsystem trees have it "easier" because they 
  have a strict hierarchy that controls essentially all changes to that 
  area of code. So they can do conflict resolution by basically doing 
  conflict _avoidance_. (The flip side is that conflict avoidance tends 
  to teach people to fight "outside" interference instead of learning 
  how to interact intelligently.)

- Lower cost of fixes, lower latency of conflict resolution: to detect
  conflicts and interaction between continuing work in each topic, and 
  with work that goes on upstream. It's much easier to resolve such 
  interactions on a clean, per topic basis than on a 'whole tree' basis. 
  The sooner we detect trouble, the faster we can act. Also, we can 
  often detect interaction right when it happens: when the other party 
  is still "active" in pursuing that other, interacting topic - this is 
  the time when fixes are the cheapest and where any change of plans is 
  the cheapest as well.

- Inability to predict future conflicts: we cannot predict the future, 
  so we dont know it _in advance_ when conflicts or interactions occur. 
  So we kept topics rolled forward on a daily basis. This spreads out
  our workload quite a bit, and also makes any trouble easier to 
  repair: a same-day bugreport or reverts are much easier for all 
  parties involved than a revert 1 or 2 weeks later, when everyone has 
  already forgotten the details of that change and is busy in another 
  topic.

- Stability: our experience is that after the merge window, the 
  stability of the upstream kernel increases near monotonically. By 
  keeping a topic branch merged daily, the practical stability of each 
  topic branch is 1-7 days better than if we merged to it weekly.

We've done tons of non-trivial conflict resolutions in the past ~5 years 
against a 'hostile' (well, indifferent) upstream tree. So we've learned 
how to do this rather efficiently in the long run [ while still staying 
sane and productive :) ], and one of the key things was to have a daily 
merge cycle.

The reason is that the best way to do conflict resolution IMO is either 
to do hard-core conflict avoidance, or to use our "finegrained roll 
forward" method: to have a topic merged cleanly to just before the point 
where the conflict happens, and then to resolve the conflict by also 
merging to just after the conflict. This means there's the least 
possible amount of unrelated flux to look at.

The reasons you cited for not having that many merge commits are of 
course all valid (graphical output and bisectability) - and they trump 
our concerns because they affect the 'end result' tree which might not 
care about our sub-tree and development concerns. (I wish we extended 
such thinking to make the tree even more bisectable than it is today - 
but that attacks the append-only nature of the tree.)

	Ingo

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Sat, 17 May 2008, Ingo Molnar wrote:
> 
> We've solved it by still doing the merges (we _need_ the information 
> about potential upcoming merge trouble), but we dont commit them to the 
> topic branches - we throw them away.

And that is *absolutely* the right thing to do.

Poeple need to test the different topic branches together some way anyway, 
regardless of upcoming merge trouble, so yes, when you have more than one 
branch, you inevitably need to have a "test branch" that ties them all 
together for testing the end result (and that test branch generally would 
be a throw-away one, like linux-next. In fact, it could *be* linux-next, 
but there's good reason for you to test your own branches together rather 
than waiting for an external entity to notice that your branches don't 
work together).

So yes, sounds good.

			Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Junio C Hamano]

Theodore Tso <tytso@mit.edu> writes:

> Basically, this would be the subsystem maintainer sometimes wearing an
> "end-point-developer" hat, and sometimes wearing a "subsystem
> maintainer" hat.  So rebasing is fine as long as it's clear that it's
> happening on branches which are not meant as a base for
> submaintainers.  
>
> I believe Junio does this himself for his own topic branches while
> developing git, yes?

Yes, I used to and I still do sometimes.  Anything not merged to 'next'
yet is a fair game for rebasing.  'pu' is strictly a patch queue in that
sense.

When I am shuffling the topics that are not merged to 'next', I am not
just wearing an end-point-developer hat, but pretending to be the original
contributor (iow "how the patch could have been done better than the one
that I received via e-mail") more often than not these days; I am writing
less and less new code myself.

I used to religiously rebase topics that were not in 'next' on top of
updated 'master' before I rebuilt 'pu' [*1*].  This was partly because
when the topic eventually becomes 'next' worthy, the commit on 'next' to
merge the topic will not have a parent that is too stale (and graphically
the end result would look easier to view that way) if I did so, and partly
because rebasing is one cheap way to detect and resolve conflicts with
'master' much earlier before the topic becomes ready to be merged to
'next'.

I do not however do that so often anymore.

Whenever I rebuild 'pu' starting from the tip of 'next', merging these
uncooked topics, if they have conflicts with 'master' or 'next', I'd
resolve them right there.  Next day, when I rebuild 'pu' again from
updated 'next', it is very likely that I have to resolve the _same_
conflicts again, but that process is largely automated because git
remembers the conflict resolution I did when I merged that topic to 'pu'
the previous day.  After the topics are polished further and when they are
ready to be merged to 'next', the story is the same.  The same conflicts
need to be resolved but that is largely automated.  That is one of the
reasons I do not rebase topics as often as I used to these days.  IOW, I
rely on and trust "rerere" magic a bit more than I used to.

[Footnote]

*1* My "git day" goes like:

 - advance 'maint' with obviously good patches, merges from completed
   'maintenance' topics, and merges from subsystem trees;

 - merge updated 'maint' to 'master';

 - advance 'master' with obviously good patches, merges from completed
   topics, and merges from subsystem trees;

 - merge updated 'master' to 'next';

 - apply new patches into new topics forked from either 'maint' (if it
   should eventually fix breakage in the maintenance track), 'master', or
   some existing topic (if it has functional dependencies on it);

 - apply update patches to existing topics;

 - possibly rebase topics that have not been in 'next' but are now ready
   for 'next';

 - merge topics that are 'next' worthy to 'next';

 - reset 'pu' to 'next';

 - merge remaining topics to 'pu';

Re: [GIT pull] x86 fixes for 2.6.26

[Thomas Gleixner]

Linus,

On Sat, 17 May 2008, Linus Torvalds wrote:
> and in that sense they look very much non-managerial. But those ~200 
> commits are still just two hundred out of 1900 commits total! We *need* 
> managers, not just grunts. And I can well imagine how stressful it is to 
> not just do the two hundred commits, but also try to orchestrate the other 
> ~1700 ones.

Hey, I can confirm that. :)

One of the main obstacles of going a more managerial way is that x86
is not yet in a shape which allows us to have real independent topic
branches. The other one is the way we worked for 5 years in
maintaining the preempt-rt patch and the related subprojects which
trickled slowly into mainline. The second obstacle is the one which is
easier to overcome.

The work which was started by the x86 merger is still in progress and
there is aside of the obvious "merge the two _32/_64 versions" a lot
of work necessary to distangle stuff which is intermingled across the
arch/x86 code base for historic reason.

The balancing act between cleaning up these problems and at the same
time not stalling further development completely is what causes quite
a lot of work and in consequence the headaches with our repository
management.

We are not yet at a point where we can rely on a probabilistic non
conflict of e.g. mcheck changes with boot process modifications.

We made pretty good progress to get there, but it would be naive to
say that we are ready for a pure topic related reliance on downstream
developers, which you can observe for example in networking. And
networking did not switch into this mode from one day to the other
either and has the luxory of a rather clean code base which makes it
easy to have clearly separated and (most of the time) independent
topic branches.

I really want to emphasise that the developers who were confronted by
us with the request to clean up stuff _before_ adding new features
were very cooperative and are responsible for the majority of the 1900
commits which we juggled into shape. If you have a close look at the
nature of the commits which were done by Ingo and me, you'll notice
that they are often just the fixup of the fallout of this patch
flood. Honestly, I did not imagine that the uptake of the new x86 tree
would be so huge.

We know that we need to adjust our workflow and trim it into the
lazy^Wmanagerial direction, but this needs some time to establish the
"independent" sub topics and find out those downstream developers who
are willing and capable to do their own topic. This is something which
does not happen overnight, but you are right that providing a stable
base to work on and an append-only forest of topic trees/branches is
definitely helpful.

Thanks,

	tglx

Re: [GIT pull] x86 fixes for 2.6.26

[Thomas Gleixner]

On Sat, 17 May 2008, Linus Torvalds wrote:
> On Sat, 17 May 2008, Ingo Molnar wrote:
> > 
> > We've solved it by still doing the merges (we _need_ the information 
> > about potential upcoming merge trouble), but we dont commit them to the 
> > topic branches - we throw them away.
> 
> And that is *absolutely* the right thing to do.
> 
> Poeple need to test the different topic branches together some way anyway, 
> regardless of upcoming merge trouble, so yes, when you have more than one 
> branch, you inevitably need to have a "test branch" that ties them all 
> together for testing the end result (and that test branch generally would 
> be a throw-away one, like linux-next. In fact, it could *be* linux-next, 
> but there's good reason for you to test your own branches together rather 
> than waiting for an external entity to notice that your branches don't 
> work together).
> 
> So yes, sounds good.

In meantime - until we sorted out our new git life - can you please
pull the fixes without the noisy merge commits (resolved by rebasing
to keep thing rolling) from:

 ssh://master.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus 

Thanks,
	tglx

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Sat, 17 May 2008, Thomas Gleixner wrote:
> 
> In meantime - until we sorted out our new git life - can you please
> pull the fixes without the noisy merge commits (resolved by rebasing
> to keep thing rolling) from:

Pulled.

		Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Jesper Juhl]

2008/5/17 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Fri, 16 May 2008, Theodore Tso wrote:
>>
>> Why do you consider rebasing topic branches a bad thing?
>
> Rebasing branches is absolutely not a bad thing for individual developers.
>
> But it *is* a bad thing for a subsystem maintainer.
>
<snip very nice description of when to use rebase>
>
> BUT if you're a subsystem maintainer, and other people are supposed to be
> able to pull from you, and you're supposed to merge other peoples work,
> then rebasing is a *horrible* workflow.
>
<snip stuff on fetch + merge>
> In other words, I very heavily would suggest that subsystem maintainers -
> at least of the bigger subsystems, really see themselves as being in the
> same situation I am: rather than doing the work, trying to make it easy
> for *others* to do the work, and then just pulling the result.
>

Linus,

Thank you for some very good descriptions on proper git workflow. That
was very informative.

As new Trivial tree maintainer I'm trying to figure out how I should
manage that tree, and based on your description on git use I have a
few questions.

What I did for my first merge-window was simply clone your tree,
create a for-linus branch, add all the patches to that branch and ask
you to pull. That worked nicely that once, but I guess that wiping the
tree and starting from a fresh clone every merge window wouldn't be a
good idea - especially since I'd like Trivial to also get pulled into
linux-next.

This is what I think I should be doing going forward. I'd appreciate
it if you could comment on whether or not it's the right way to do
things.

Start off with a clone of your tree (master branch).

Pull your tree into 'master' daily (or at least often).

Create a for-linux-2.6.27 branch or the upcomming 2.6.27 merge window
and apply all the patches I currently have pendng in a mailbox to that
branch. Keep the branch reasonably up-to-date by doing a weekly git
fetch + merge from my 'master' branch that tracks your tree.

Once the 2.6.27 merge window opens, ask you to pull the
'for-linux-2.6.27' branch and once you have done so, leave that branch
alone forever.

Branch off a new 'for-linux-2.6.28' branch and repeat.

As for linux-next, I'd create a 'linux-next' branch that I would
update whenever I change one of the 'for-linux-2.6.xx' branches, by
doing a fetch from the branch into 'linux-next' and then a merge.

Does that sound sane or is there a better way?


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Sun, 18 May 2008, Jesper Juhl wrote:
> 
> What I did for my first merge-window was simply clone your tree,
> create a for-linus branch, add all the patches to that branch and ask
> you to pull. That worked nicely that once, but I guess that wiping the
> tree and starting from a fresh clone every merge window wouldn't be a
> good idea - especially since I'd like Trivial to also get pulled into
> linux-next.

Well, I actually suspect that especially for the trivial tree, that may 
not actually be a horribly bad workflow. 

The whole "fresh clone + a bunch of patches" is yet another different way 
of using git, but it's a totally valid one: it uses git as just another 
way to send a patch-series, with the added advantage that the base of that 
patch-series is explicit in the result.

(You can do that with quilt too, I think. Or at least with the scripts 
Andrew does - I think you can tell him what the base point for a series 
is. But when merging to me, git is obviously the way to go).

So for something that pretty fundamentally is literally just a series of 
random patches, I don't think the workflow of just staging them as a 
series on top of some known-good git tree is the wrong one. It's not like 
the Trivial tree is likely to be something that would have much use of git 
as a distributed model (iow - I think the trivial patches are actually 
better off seen as a patch-queue than having merges and other things in 
it).

That said, re-cloning every time is obviously pretty wasteful. There are 
better ways to track a git tree, notably it's likely best to just clone 
once and then just keep that one up-to-date. But the difference between 
that and just re-cloning is really not that huge - technically you'd end 
up doing the exact same thing and have the exact same tree, just two 
different ways to do it.

So your alternate approach:

> Start off with a clone of your tree (master branch).
> 
> Pull your tree into 'master' daily (or at least often).

So doing daily pull's is what I generally do *not* want people to do, but 
if you have a pristine tree and haven't done any development of your own, 
then the "pull" is obviously not going to do anything but keep the tree 
fresh, so in this special case it's fine.

So you'd not be merging, you'd be just refreshing your clone - and in that 
sense this is 100% equivalent to just re-cloning all the time.

> Create a for-linux-2.6.27 branch or the upcomming 2.6.27 merge window
> and apply all the patches I currently have pendng in a mailbox to that
> branch. Keep the branch reasonably up-to-date by doing a weekly git
> fetch + merge from my 'master' branch that tracks your tree.

So generally, I'd suggest against this "keep it fresh". In many ways it 
just makes things harder (if only because bisection of your series will no 
longer be a nice linear run, but also because the history will actually be 
harder to read), and if the merges are just weekly regular merges, then 
the purpose of them isn't even very clear.

So I'd literally suggest doing merges primarily only

 - at release points (now the purpose is clear; you're merging a very 
   specific state, not just some random point).

   But even this one should generally be done only if there is some real 
   reason for it (ie you're really quite far behind), and 

 - or if you actually see a merge conflict, and you want to handle the 
   conflict so that I won't have to.

   But I'll actually happily handle trivial merges too, so this is by no 
   means even a requirement - if the merge ends up being non-trivial, I'll 
   let people know anyway and either say "ok, that's so complicated, and I 
   don't know the area well enough, so can you please do it for me", or 
   say "ok, I merged it, but can you please double-check the result".

Quite frankly, if you actually do your patch-series pretty late in the -rc 
series (say, you decide to apply things at -rc6 or so), I suspect you'll 
never have any real reason to do a "git pull" at all, although it's also 
certainly not wrong to do test branches to check that everything is ok, 
for example.

> Once the 2.6.27 merge window opens, ask you to pull the
> 'for-linux-2.6.27' branch and once you have done so, leave that branch
> alone forever.
>
> Branch off a new 'for-linux-2.6.28' branch and repeat.

Yes. That's a good model.

			Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

Hi Jesper,

On Sat, 17 May 2008 17:35:44 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>    But I'll actually happily handle trivial merges too, so this is by no 
>    means even a requirement - if the merge ends up being non-trivial, I'll 
>    let people know anyway and either say "ok, that's so complicated, and I 
>    don't know the area well enough, so can you please do it for me", or 
>    say "ok, I merged it, but can you please double-check the result".

This is also true for linux-next.

> > Once the 2.6.27 merge window opens, ask you to pull the
> > 'for-linux-2.6.27' branch and once you have done so, leave that branch
> > alone forever.
> >
> > Branch off a new 'for-linux-2.6.28' branch and repeat.
> 
> Yes. That's a good model.

I just have one request: instead of calling it for-linux-2.6.27, call it
for-next.  The when the merge window opens rename it to for-linus or
current or something and reset for-next to where you want to start
collecting stuff for 2.6.28.  That way you don't have to keep telling me
where the tree I fetch into linux-next is.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [GIT pull] x86 fixes for 2.6.26

[Jesper Juhl]

2008/5/18 Linus Torvalds <torvalds@linux-foundation.org>:
>

Hi Linus,

Thank you for responding. A few more small questions below.

>
> On Sun, 18 May 2008, Jesper Juhl wrote:
>>
>> What I did for my first merge-window was simply clone your tree,
>> create a for-linus branch, add all the patches to that branch and ask
>> you to pull. That worked nicely that once, but I guess that wiping the
>> tree and starting from a fresh clone every merge window wouldn't be a
>> good idea - especially since I'd like Trivial to also get pulled into
>> linux-next.
>
> Well, I actually suspect that especially for the trivial tree, that may
> not actually be a horribly bad workflow.
>
> The whole "fresh clone + a bunch of patches" is yet another different way
> of using git, but it's a totally valid one: it uses git as just another
> way to send a patch-series, with the added advantage that the base of that
> patch-series is explicit in the result.
>
> (You can do that with quilt too, I think. Or at least with the scripts
> Andrew does - I think you can tell him what the base point for a series
> is. But when merging to me, git is obviously the way to go).
>
Yeah, I figured that trying to get a good git workflow up and running
would probably be the best in the long run.


> So for something that pretty fundamentally is literally just a series of
> random patches, I don't think the workflow of just staging them as a
> series on top of some known-good git tree is the wrong one. It's not like
> the Trivial tree is likely to be something that would have much use of git
> as a distributed model (iow - I think the trivial patches are actually
> better off seen as a patch-queue than having merges and other things in
> it).
>
Right. By definition it is just a bunch of random patches queued up in
that tree so they don't get lost and so that lots of individual people
don't have to keep re-sending them.

> That said, re-cloning every time is obviously pretty wasteful. There are
> better ways to track a git tree, notably it's likely best to just clone
> once and then just keep that one up-to-date. But the difference between
> that and just re-cloning is really not that huge - technically you'd end
> up doing the exact same thing and have the exact same tree, just two
> different ways to do it.
>
> So your alternate approach:
>
>> Start off with a clone of your tree (master branch).
>>
>> Pull your tree into 'master' daily (or at least often).
>
> So doing daily pull's is what I generally do *not* want people to do, but
> if you have a pristine tree and haven't done any development of your own,
> then the "pull" is obviously not going to do anything but keep the tree
> fresh, so in this special case it's fine.
>
Good.

> So you'd not be merging, you'd be just refreshing your clone - and in that
> sense this is 100% equivalent to just re-cloning all the time.
>
>> Create a for-linux-2.6.27 branch or the upcomming 2.6.27 merge window
>> and apply all the patches I currently have pendng in a mailbox to that
>> branch. Keep the branch reasonably up-to-date by doing a weekly git
>> fetch + merge from my 'master' branch that tracks your tree.
>
> So generally, I'd suggest against this "keep it fresh". In many ways it
> just makes things harder (if only because bisection of your series will no
> longer be a nice linear run, but also because the history will actually be
> harder to read), and if the merges are just weekly regular merges, then
> the purpose of them isn't even very clear.
>
> So I'd literally suggest doing merges primarily only
>
>  - at release points (now the purpose is clear; you're merging a very
>   specific state, not just some random point).
>
<snip>

Ok, so let's say I start off my upcomming trivial branch at -rc1 and
start applying patches to it, then doing a merge with my master branch
that tracks your tree at points like, say, -rc5, -rc9 etc would be
fine, but really only needed if there are conflicts (which I can test
for in a temporary experimental branch) - got it.

>> Once the 2.6.27 merge window opens, ask you to pull the
>> 'for-linux-2.6.27' branch and once you have done so, leave that branch
>> alone forever.
>>
>> Branch off a new 'for-linux-2.6.28' branch and repeat.
>
> Yes. That's a good model.
>

Ok, thanks a lot.  Now, I have one final question for you.
In order to be able to play around with the patches, see if they
apply, fix them up, test for merge conflicts etc etc, I obviously need
a tree with content, not just a bare tree. But I see on
master.kernel.org that all the published trees are bare trees.

So, I assume I create a tree in my homedir like so;
  $ git clone -l -s /pub/scm/linux/kernel/git/torvalds/linux-2.6.git
/home/juhl/trivial-work-tree
create all the branches and do all the work in that one,

I would have assumed that to then publish my work and create a
publicly accessile version I'd do;
  $ git clone --bare -l -s /home/juhl/trivial-work-tree
/pub/scm/linux/kernel/git/juhl/trivial.git

But that only seems to make my master branch accessible, not new
branches I create in my work tree.  How do I go about doing this
properly?


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

Re: [GIT pull] x86 fixes for 2.6.26

[Linus Torvalds]

On Mon, 19 May 2008, Jesper Juhl wrote:
> 
> Ok, thanks a lot.  Now, I have one final question for you.
> In order to be able to play around with the patches, see if they
> apply, fix them up, test for merge conflicts etc etc, I obviously need
> a tree with content, not just a bare tree. But I see on
> master.kernel.org that all the published trees are bare trees.

I think just about *everybody* does their own development on their own 
machine. I know I do, and I'm pretty certain that everybody else does too. 
Then we just upload the end result to master.kernel.org into a bare 
repository that is only used for exporting to others, never for anything 
else.

> So, I assume I create a tree in my homedir like so;
>   $ git clone -l -s /pub/scm/linux/kernel/git/torvalds/linux-2.6.git /home/juhl/trivial-work-tree
> create all the branches and do all the work in that one,

You can do that, and actually work on master.kernel.org, but do you really 
want to?

It's much easier to work at home (or office, whatever - on your own 
workstation), unless you have some really weak computer.

Then, the easiest way to publish the result is to just create a bare 
repository on master.kernel.org, and push to it. And just make sure that 
you pre-populate that bare repo with my tree, so that when you push from 
your home machine, it only pushes the (smallish) actual changes!

So the workflow I'd suggest is:

 - do all the work on your own hardware

 - create the initial (bare) kernel.org tree with

	cd /pub/scm/linux/kernel/git/juhl
	git clone --bare -l -s ../torvalds/linux-2.6 trivial-2.6

 - then just push to that tree from your own machine

and voila, you're all done.

> But that only seems to make my master branch accessible, not new
> branches I create in my work tree.  How do I go about doing this
> properly?

If you do the "clone locally, then push from the remote", the "push" stage 
is when you decide which branches you'll want to push.

The easiest thing to do is to just use "--all", which will push all the 
branches to the remote (you may want to use "--force" if this ends up 
being a non-fast-forward, which can happen - for example - just because 
your "clone" might have cloned a later version of my tree than the one you 
based your own 'master' branch off).

But you can push individual branches too, see 'man git-push'.

If you really *want* to work on master.kernel.org, you can do so, and you 
can do the final clone with "git clone --mirror --bare" and use that as a 
way to clone all branches as a mirror of your work-tree, but it really is 
a fairly unusual way to work.

		Linus

Re: [GIT pull] x86 fixes for 2.6.26

[Jesper Juhl]

2008/5/19 Linus Torvalds <torvalds@linux-foundation.org>:
>
>
> On Mon, 19 May 2008, Jesper Juhl wrote:
>>
>> Ok, thanks a lot.  Now, I have one final question for you.
>> In order to be able to play around with the patches, see if they
>> apply, fix them up, test for merge conflicts etc etc, I obviously need
>> a tree with content, not just a bare tree. But I see on
>> master.kernel.org that all the published trees are bare trees.
>
> I think just about *everybody* does their own development on their own
> machine. I know I do, and I'm pretty certain that everybody else does too.
> Then we just upload the end result to master.kernel.org into a bare
> repository that is only used for exporting to others, never for anything
> else.
>
>> So, I assume I create a tree in my homedir like so;
>>   $ git clone -l -s /pub/scm/linux/kernel/git/torvalds/linux-2.6.git /home/juhl/trivial-work-tree
>> create all the branches and do all the work in that one,
>
> You can do that, and actually work on master.kernel.org, but do you really
> want to?
>
Not if I can help it, no. I just couldn't work out from the git docs
how to do it otherwise when working with kernel.org and bare trees.

<snip>
> Then, the easiest way to publish the result is to just create a bare
> repository on master.kernel.org, and push to it. And just make sure that
> you pre-populate that bare repo with my tree, so that when you push from
> your home machine, it only pushes the (smallish) actual changes!
>
> So the workflow I'd suggest is:
>
>  - do all the work on your own hardware
>
>  - create the initial (bare) kernel.org tree with
>
>        cd /pub/scm/linux/kernel/git/juhl
>        git clone --bare -l -s ../torvalds/linux-2.6 trivial-2.6
>
>  - then just push to that tree from your own machine
>
> and voila, you're all done.
>
<snip>

That worked beautifully. Thanks a lot.


Stephen: There is now a trivial-2.6.git tree at
git://git.kernel.org/pub/scm/linux/kernel/git/juhl/trivial-2.6.git
with a 'next' branch that you can pull into linux-next, please.

  git://git.kernel.org/pub/scm/linux/kernel/git/juhl/trivial-2.6.git next

Once we hit a merge window I'll rename the 'next' branch and ask Linus
to pull it, then create a new 'next'.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html

[GIT pull] x86 fixes for 2.6.26

[Thomas Gleixner]

Linus,

please pull x86 fixes for 2.6.26 from:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git x86-fixes-for-linus

Thanks,
	tglx
---
Andi Kleen (1):
      x86: use explicit copy in vdso_gettimeofday()

Chuck Ebbert (1):
      x86: don't read maxlvt before checking if APIC is mapped

Ingo Molnar (2):
      namespacecheck: automated fixes
      x86: prevent PGE flush from interruption/preemption

Jan Beulich (1):
      x86/xen: fix arbitrary_virt_to_machine()

Thomas Gleixner (3):
      x86: fix setup of cyc2ns in tsc_64.c
      x86: distangle user disabled TSC from unstable
      x86: disable TSC for sched_clock() when calibration failed

 arch/x86/kernel/apic_64.c      |    2 +-
 arch/x86/kernel/kvmclock.c     |    4 ++--
 arch/x86/kernel/tsc_32.c       |   25 +++++++++++++++----------
 arch/x86/kernel/tsc_64.c       |    5 +++--
 arch/x86/kvm/mmu.c             |    2 +-
 arch/x86/vdso/vclock_gettime.c |    6 +++---
 arch/x86/xen/mmu.c             |    2 +-
 include/asm-x86/tlbflush.h     |   13 ++++++++++++-
 8 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kernel/apic_64.c b/arch/x86/kernel/apic_64.c
index 5910020..0633cfd 100644
--- a/arch/x86/kernel/apic_64.c
+++ b/arch/x86/kernel/apic_64.c
@@ -534,7 +534,7 @@ int setup_profiling_timer(unsigned int multiplier)
  */
 void clear_local_APIC(void)
 {
-	int maxlvt = lapic_get_maxlvt();
+	int maxlvt;
 	u32 v;
 
 	/* APIC hasn't been mapped yet */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index 4bc1be5..08a3098 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -53,7 +53,7 @@ static cycle_t kvm_clock_read(void);
  * have elapsed since the hypervisor wrote the data. So we try to account for
  * that with system time
  */
-unsigned long kvm_get_wallclock(void)
+static unsigned long kvm_get_wallclock(void)
 {
 	u32 wc_sec, wc_nsec;
 	u64 delta;
@@ -86,7 +86,7 @@ unsigned long kvm_get_wallclock(void)
 	return ts.tv_sec + 1;
 }
 
-int kvm_set_wallclock(unsigned long now)
+static int kvm_set_wallclock(unsigned long now)
 {
 	return 0;
 }
diff --git a/arch/x86/kernel/tsc_32.c b/arch/x86/kernel/tsc_32.c
index e479072..068759d 100644
--- a/arch/x86/kernel/tsc_32.c
+++ b/arch/x86/kernel/tsc_32.c
@@ -14,7 +14,7 @@
 
 #include "mach_timer.h"
 
-static int tsc_enabled;
+static int tsc_disabled;
 
 /*
  * On some systems the TSC frequency does not
@@ -28,8 +28,8 @@ EXPORT_SYMBOL_GPL(tsc_khz);
 static int __init tsc_setup(char *str)
 {
 	printk(KERN_WARNING "notsc: Kernel compiled with CONFIG_X86_TSC, "
-				"cannot disable TSC completely.\n");
-	mark_tsc_unstable("user disabled TSC");
+	       "cannot disable TSC completely.\n");
+	tsc_disabled = 1;
 	return 1;
 }
 #else
@@ -120,7 +120,7 @@ unsigned long long native_sched_clock(void)
 	 *   very important for it to be as fast as the platform
 	 *   can achive it. )
 	 */
-	if (unlikely(!tsc_enabled && !tsc_unstable))
+	if (unlikely(tsc_disabled))
 		/* No locking but a rare wrong value is not a big deal: */
 		return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);
 
@@ -322,7 +322,6 @@ void mark_tsc_unstable(char *reason)
 {
 	if (!tsc_unstable) {
 		tsc_unstable = 1;
-		tsc_enabled = 0;
 		printk("Marking TSC unstable due to: %s.\n", reason);
 		/* Can be called before registration */
 		if (clocksource_tsc.mult)
@@ -336,7 +335,7 @@ EXPORT_SYMBOL_GPL(mark_tsc_unstable);
 static int __init dmi_mark_tsc_unstable(const struct dmi_system_id *d)
 {
 	printk(KERN_NOTICE "%s detected: marking TSC unstable.\n",
-		       d->ident);
+	       d->ident);
 	tsc_unstable = 1;
 	return 0;
 }
@@ -403,14 +402,22 @@ void __init tsc_init(void)
 {
 	int cpu;
 
-	if (!cpu_has_tsc)
+	if (!cpu_has_tsc || tsc_disabled) {
+		/* Disable the TSC in case of !cpu_has_tsc */
+		tsc_disabled = 1;
 		return;
+	}
 
 	cpu_khz = calculate_cpu_khz();
 	tsc_khz = cpu_khz;
 
 	if (!cpu_khz) {
 		mark_tsc_unstable("could not calculate TSC khz");
+		/*
+		 * We need to disable the TSC completely in this case
+		 * to prevent sched_clock() from using it.
+		 */
+		tsc_disabled = 1;
 		return;
 	}
 
@@ -441,8 +448,6 @@ void __init tsc_init(void)
 	if (check_tsc_unstable()) {
 		clocksource_tsc.rating = 0;
 		clocksource_tsc.flags &= ~CLOCK_SOURCE_IS_CONTINUOUS;
-	} else
-		tsc_enabled = 1;
-
+	}
 	clocksource_register(&clocksource_tsc);
 }
diff --git a/arch/x86/kernel/tsc_64.c b/arch/x86/kernel/tsc_64.c
index fcc16e5..1784b80 100644
--- a/arch/x86/kernel/tsc_64.c
+++ b/arch/x86/kernel/tsc_64.c
@@ -227,14 +227,14 @@ void __init tsc_calibrate(void)
 	/* hpet or pmtimer available ? */
 	if (!hpet && !pm1 && !pm2) {
 		printk(KERN_INFO "TSC calibrated against PIT\n");
-		return;
+		goto out;
 	}
 
 	/* Check, whether the sampling was disturbed by an SMI */
 	if (tsc1 == ULONG_MAX || tsc2 == ULONG_MAX) {
 		printk(KERN_WARNING "TSC calibration disturbed by SMI, "
 		       "using PIT calibration result\n");
-		return;
+		goto out;
 	}
 
 	tsc2 = (tsc2 - tsc1) * 1000000L;
@@ -255,6 +255,7 @@ void __init tsc_calibrate(void)
 
 	tsc_khz = tsc2 / tsc1;
 
+out:
 	for_each_possible_cpu(cpu)
 		set_cyc2ns_scale(tsc_khz, cpu);
 }
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 36c5406..7246b60 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -1996,7 +1996,7 @@ static struct shrinker mmu_shrinker = {
 	.seeks = DEFAULT_SEEKS * 10,
 };
 
-void mmu_destroy_caches(void)
+static void mmu_destroy_caches(void)
 {
 	if (pte_chain_cache)
 		kmem_cache_destroy(pte_chain_cache);
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 23476c2..efa2ba7 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -106,9 +106,9 @@ int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz)
 		do_realtime((struct timespec *)tv);
 		tv->tv_usec /= 1000;
 		if (unlikely(tz != NULL)) {
-			/* This relies on gcc inlining the memcpy. We'll notice
-			   if it ever fails to do so. */
-			memcpy(tz, &gtod->sys_tz, sizeof(struct timezone));
+			/* Avoid memcpy. Some old compilers fail to inline it */
+			tz->tz_minuteswest = gtod->sys_tz.tz_minuteswest;
+			tz->tz_dsttime = gtod->sys_tz.tz_dsttime;
 		}
 		return 0;
 	}
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 126766d..3525ef5 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -60,7 +60,7 @@ xmaddr_t arbitrary_virt_to_machine(unsigned long address)
 {
 	unsigned int level;
 	pte_t *pte = lookup_address(address, &level);
-	unsigned offset = address & PAGE_MASK;
+	unsigned offset = address & ~PAGE_MASK;
 
 	BUG_ON(pte == NULL);
 
diff --git a/include/asm-x86/tlbflush.h b/include/asm-x86/tlbflush.h
index 0c0674d..35c76ce 100644
--- a/include/asm-x86/tlbflush.h
+++ b/include/asm-x86/tlbflush.h
@@ -22,12 +22,23 @@ static inline void __native_flush_tlb(void)
 
 static inline void __native_flush_tlb_global(void)
 {
-	unsigned long cr4 = read_cr4();
+	unsigned long flags;
+	unsigned long cr4;
 
+	/*
+	 * Read-modify-write to CR4 - protect it from preemption and
+	 * from interrupts. (Use the raw variant because this code can
+	 * be called from deep inside debugging code.)
+	 */
+	raw_local_irq_save(flags);
+
+	cr4 = read_cr4();
 	/* clear PGE */
 	write_cr4(cr4 & ~X86_CR4_PGE);
 	/* write old PGE again and flush TLBs */
 	write_cr4(cr4);
+
+	raw_local_irq_restore(flags);
 }
 
 static inline void __native_flush_tlb_single(unsigned long addr)