[GIT PULL] SLAB changes for v2.6.38

[GIT PULL] SLAB changes for v2.6.38

[Pekka Enberg]

Hi Linus,

It's been rather quiet for slab allocators this merge cycle. There's only 
few cleanups here. The bug fixes were merged in v2.6.37 already. As they 
were cherry-picked from this branch, they show up in the pull request 
(what's up with that btw).

                         Pekka

The following changes since commit 0c21e3aaf6ae85bee804a325aa29c325209180fd:
   Linus Torvalds (1):
         Merge branch 'for-next' of git://git.kernel.org/.../hch/hfsplus

are available in the git repository at:

   ssh://master.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git for-linus

Christoph Lameter (1):
       slub: move slabinfo.c to tools/slub/slabinfo.c

Pavel Emelyanov (1):
       slub: Fix slub_lock down/up imbalance

Pekka Enberg (2):
       slub: Fix build breakage in Documentation/vm
       Merge branch 'slab/next' into for-linus

Richard Kennedy (1):
       slub tracing: move trace calls out of always inlined functions to reduce kernel code size

Steven Rostedt (1):
       tracing/slab: Move kmalloc tracepoint out of inline code

Tero Roponen (1):
       slub: Fix a crash during slabinfo -v

  Documentation/vm/Makefile                   |    2 +-
  include/linux/slab_def.h                    |   33 ++++++----------
  include/linux/slub_def.h                    |   55 +++++++++++++--------------
  mm/slab.c                                   |   38 +++++++++++-------
  mm/slub.c                                   |   30 +++++++++++---
  {Documentation/vm => tools/slub}/slabinfo.c |    6 +-
  6 files changed, 89 insertions(+), 75 deletions(-)
  rename {Documentation/vm => tools/slub}/slabinfo.c (99%)

Re: [GIT PULL] SLAB changes for v2.6.38

[Linus Torvalds]

On Sun, Jan 9, 2011 at 1:13 AM, Pekka Enberg <penberg@kernel.org> wrote:
>
> It's been rather quiet for slab allocators this merge cycle. There's only
> few cleanups here. The bug fixes were merged in v2.6.37 already. As they
> were cherry-picked from this branch, they show up in the pull request
> (what's up with that btw).

For the "what's up with that btw" department:

A cherry-pick really is nothing but "apply the same patch as a
different commit".

So there is no way to say "this is already there" - because it really
isn't. It's a totally different thing. In fact, it would be very wrong
to filter them out, both from a fundamental design standpoint, but
also from a usability/reliability standpoint: cherry-picks are by no
means guaranteed to be identical to the source - like any "re-apply
the patch in another place" model, the end result is not at all
guaranteed to be semantically identical simply due to different bases:
the patches may not even be identical, and even if they are, the
results of the code may depend on what else is going on.

So don't think of cherry-picks as "the same commit". It's not, and it
never will be. It's a totally separate commit, they just share some
superficial commonalities.

                    Linus

Re: [GIT PULL] SLAB changes for v2.6.38

[Pekka Enberg]

Hi Linus,

On Mon, Jan 10, 2011 at 6:44 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> A cherry-pick really is nothing but "apply the same patch as a
> different commit".
>
> So there is no way to say "this is already there" - because it really
> isn't. It's a totally different thing. In fact, it would be very wrong
> to filter them out, both from a fundamental design standpoint, but
> also from a usability/reliability standpoint: cherry-picks are by no
> means guaranteed to be identical to the source - like any "re-apply
> the patch in another place" model, the end result is not at all
> guaranteed to be semantically identical simply due to different bases:
> the patches may not even be identical, and even if they are, the
> results of the code may depend on what else is going on.
>
> So don't think of cherry-picks as "the same commit". It's not, and it
> never will be. It's a totally separate commit, they just share some
> superficial commonalities.

OK, I did not know that. Thanks for the explanation!

Is cherry pick still sane from maintainer workflow point of view? I
used to do it the other way - merge bug fixes to an "urgent branch"
and then merge that to the "next branch". I changed my workflow to
apply the patches always to the "next branch" first and only cherry
pick to the "urgent branch" if necessary.

Am I doing it wrong?

                        Pekka

Re: [GIT PULL] SLAB changes for v2.6.38

[Linus Torvalds]

On Tue, Jan 11, 2011 at 2:41 AM, Pekka Enberg <penberg@kernel.org> wrote:
>
> Is cherry pick still sane from maintainer workflow point of view?

Yes, if it's the occasional random thing that happens once or twice,
it's much easier than a separate branch and merging it into other
branches.

We have the exact same thing happen every once in a while simply
because two people apply the same emailed patch to their trees. You
end up with the same diff and the same message. Yeah, it's not called
a "cherry-pick" then, but there's really not any technical difference
apart from the commands to generate the "duplicate" commits.

It can become a problem if there's a _lot_ of it going on, though. It
can cause subsequent merge issues if there are other changes in the
same area, for example. And it can be a sign of some bad workflow.

You could also simply think of it in terms of "number of extra
commits". If you cherry-pick and it shows up as one extra commit,
that's still easier to understand and fewer overall commits than
having a separate branch with just one commit, and then two merge
commits - to merge that special branch into the two branches you care
about.

Using that rough guideline, if you have three or more of these, it
would actually be better to have them in one branch, and then merge
that stable branch twice - fewer extraneous commits (but that also
requires that you don't merge after each one.

That said, "number of commits" is not a really meaningful measure
either. I really tend to like how the ACPI tree does things, with
separate branches for separate bugzilla entries - with nice relevant
branch naming (bug number or description) - and then merging them. At
that point you may well have a branch with just a single commit in it,
but now the extra merge actually _adds_ information and the history
looks better for it.

So there are no hard rules. I personally use "gitk" after pulling, and
quite frankly, "clean history" is pretty damn obvious.

                                Linus

Re: [GIT PULL] SLAB changes for v2.6.38

[Tony Luck]

On Tue, Jan 11, 2011 at 8:13 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

> That said, "number of commits" is not a really meaningful measure
> either. I really tend to like how the ACPI tree does things, with
> separate branches for separate bugzilla entries - with nice relevant
> branch naming (bug number or description) - and then merging them. At
> that point you may well have a branch with just a single commit in it,
> but now the extra merge actually _adds_ information and the history
> looks better for it.

There are some notes on this work flow in the git sources in
Documentation/user-manual.txt in the [[maintaining-topic-branches]]
chapter.

-Tony