login
Search
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 ...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 --
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 --
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 ...
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 --
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 ...
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. 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 ...
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 ...
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 ...
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 ...
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/
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 --
