How do I remove a patch buried in your *-mm series?

How do I remove a patch buried in your *-mm series?

[Paul Jackson]

I want to remove the patch in *-mm:

  1) cpuset-change-marker-for-relative-numbering.patch

Unfortunately, it collides with another couple cpuset patches later in
your stack:

  2) cpuset-memory-pressure-meter.patch, cpuset-memory-pressure-meter-gcc-295-fix.patch

How should I do this so I minimize the amount of cussing you do in my
general direction:

  A. Just ask you to nuke patch (1) above; let you edit the mess.
  B. Ask you to nuke both (1) and (2); leave me to resend a (2) that applies.
  C. Send a reversing patch that applies on top of your current *-mm stack.
  D. Some other plan you would prefer.

I have verified that removing all the patches above applies cleanly and
builds, with just a harmless -74 lines offset on one of the remaining
cpuset patches.

  So I recommend B.

Separately I will send a patch to remove the bit of Documentation/cpusets.txt
that described this feature.

Details for the historical record:
  I either need to go one step forward with it (fix a bug so that
  it zeros the marker_pid of the left behind cpuset when attach_task
  moves a task), or I need to go five steps backward, with a different
  approach.  But I have other stuff to do first, so should avoid
  digging this "change-marker-for-relative-numbering" any deeper
  than it is for now.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: How do I remove a patch buried in your *-mm series?

[Andrew Morton]

Paul Jackson <pj@sgi.com> wrote:
>
> I want to remove the patch in *-mm:
> 
>   1) cpuset-change-marker-for-relative-numbering.patch
> 
> Unfortunately, it collides with another couple cpuset patches later in
> your stack:
> 
>   2) cpuset-memory-pressure-meter.patch, cpuset-memory-pressure-meter-gcc-295-fix.patch
> 
> How should I do this so I minimize the amount of cussing you do in my
> general direction:
> 
>   A. Just ask you to nuke patch (1) above; let you edit the mess.
>   B. Ask you to nuke both (1) and (2); leave me to resend a (2) that applies.
>   C. Send a reversing patch that applies on top of your current *-mm stack.
>   D. Some other plan you would prefer.

    E.  You send a _minimal_ patch against lastest mm, telling me
       "this fixes a bug in
       cpuset-change-marker-for-relative-numbering.patch".  Then I insert
       it into the series with name
       cpuset-change-marker-for-relative-numbering-fix.patch and it gets
       folded into cpuset-change-marker-for-relative-numbering.patch prior
       to going to Linus.

Usually people forget to tell me which patch it fixes, but I work it out.

In this case, dropping cpuset-change-marker-for-relative-numbering.patch
works fine too - it took 20 seconds to fix up the rejects.  Mainly by
simply omitting them, because all this stuff:

***************
*** 191,199 ****
  	.cpus_allowed = CPU_MASK_ALL,
  	.mems_allowed = NODE_MASK_ALL,
  	.marker_pid = 0,
- 	.fmeter.cnt = 0,
- 	.fmeter.val = 0,
- 	.fmeter.time = 0,
  	.count = ATOMIC_INIT(0),
  	.sibling = LIST_HEAD_INIT(top_cpuset.sibling),
  	.children = LIST_HEAD_INIT(top_cpuset.children),
--- 191,201 ----
  	.cpus_allowed = CPU_MASK_ALL,
  	.mems_allowed = NODE_MASK_ALL,
  	.marker_pid = 0,
+ 	.fmeter = {
+ 		.cnt = 0,
+ 		.val = 0,
+ 		.time = 0,
+ 	},
  	.count = ATOMIC_INIT(0),
  	.sibling = LIST_HEAD_INIT(top_cpuset.sibling),
  	.children = LIST_HEAD_INIT(top_cpuset.children),


It just redundant - the compiler does that.

> I have verified that removing all the patches above applies cleanly and
> builds, with just a harmless -74 lines offset on one of the remaining
> cpuset patches.
> 
>   So I recommend B.

Your call.  E is preferred though.

Re: How do I remove a patch buried in your *-mm series?

[Paul Jackson]

Andrew wrote:
    E. You send a _minimal_ patch ... prior
       to going to Linus.

No!  This isn't (for now at least) a fix.  It's a nuke.

I don't want that "cpuset-change-marker-for-relative-numbering.patch"
going to Linus, because I am hesitating whether I even want that
"feature".

I want to nuke it now.  You might see it again, fixed up, or you
might never see it again (I doubt you'll miss it ;).  I don't
know yet.

Yes - the collisions resulting from removing this patch are easy to edit,
if that fits your style.  If you hadn't removed the useless silly
zero initializers, I would have in my next set patches.  It was on
my todo list, thanks to an earlier comment of yours.

So ... not E ;).  What's your preference now?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: How do I remove a patch buried in your *-mm series?

[Andrew Morton]

Paul Jackson <pj@sgi.com> wrote:
>
> So ... not E ;).  What's your preference now?

http://www.zip.com.au/~akpm/linux/patches/stuff/x.bz2 is a patch against
-rc4 containing everything in -mm up to and including 

...
radix-tree-code-consolidation
radix_tree-early-termination-of-tag-clearing
radix-tree-reduce-tree-height-upon-partial-truncation
slob-introduce-mm-utilc-for-shared-functions
slob-introduce-the-slob-allocator
slob-introduce-the-slob-allocator-fixes
cpuset-better-bitmap-remap-defaults
cpuset-mempolicy-one-more-nodemask-conversion
cpuset-memory-pressure-meter
cpuset-memory-pressure-meter-gcc-295-fix
cpuset-document-additional-features

So a patch against that will be ideal.

(It's very easy for me to create such a rollup - one has but to ask...)

Re: How do I remove a patch buried in your *-mm series?

[Paul Jackson]

Andrew wrote:
> So a patch against that will be ideal.

Ok - the "change-marker-for-relative-numbering" patch I wanted gone is
gone.  Good.

I don't know what "patch against that" you have in mind.  But I guess
that doesn't matter.

I will make sure I am in sync with that rc4 + that mm rollup patch +
whatever else follows it in mm, for whatever other work I do.

Thanks.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401