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 se...
[ message continues ]

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

--

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

--

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" th...
[ message continues ]

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

--

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 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 
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 r...
[ message continues ]

Hi Linus,
Yeah, I figured that trying to get a good git workflow up and running

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

<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
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

--

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 
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
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

--

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>
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

--

Hi Jesper,
On Sat, 17 May 2008 17:35:44 -0700 (PDT) Linus Torvalds <torvalds@linux-fou=
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.
--=20

Cheers,

Stephen Rothwell                    sfr@canb.auug.org.au

http://www.canb.auug.org.au/~sfr/

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
Heh, can't really argue with your point here.
							- Ted

--

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 'mast...
[ message continues ]

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 
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:
	...
[ message continues ]

Linus,
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 direc...
[ message continues ]

We have topic branches. How should we keep those topic branches up
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
--

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 
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

--

From: Linus Torvalds <torvalds@linux-foundation.org>
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.

--

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, 
Yes. I think you guys already have a test branch for the "join it all

together" case, don't you?
		Linus

--

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...
[ message continues ]

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

--

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

--

Pulled.
		Linus

--

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

--