From: "Martin J. Bligh" <mbligh@mbligh.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Rik van Riel <riel@redhat.com>,
a.p.zijlstra@chello.nl, linux-mm@kvack.org, torvalds@osdl.org,
piggin@cyberone.com.au, linux-kernel@vger.kernel.org,
Andy Whitcroft <apw@shadowen.org>
Subject: Re: [PATCH] mm: use-once cleanup
Date: Thu, 27 Jul 2006 07:05:03 -0700 [thread overview]
Message-ID: <44C8C80F.8010705@mbligh.org> (raw)
In-Reply-To: <20060727011204.87033366.akpm@osdl.org>
>>Peter Zijlstra wrote:
>>
>>
>>>Hi,
>>>
>>>This is yet another implementation of the PG_useonce cleanup spoken of
>>>during the VM summit.
>>>
>>>
>>After getting bitten by rsync yet again, I guess it's time to insist
>>that this patch gets merged...
>>
>>Andrew, could you merge this? Pretty please? ;)
>>
>>
>>
>
>Guys, this is a performance patch, right?
>
>One which has no published performance testing results, right?
>
>It would be somewhat odd to merge it under these circumstances.
>
>And this applies to all of these
>hey-this-is-cool-but-i-didnt-bother-testing-it MM patches which people are
>throwing around. This stuff is *hard*. It has a bad tendency to cause
>nasty problems which only become known months after the code is merged.
>
>I shouldn't have to describe all this, but
>
>- Identify the workloads which it's supposed to improve, set up tests,
> run tests, publish results.
>
>- Identify the workloads which it's expected to damage, set up tests, run
> tests, publish results.
>
>- Identify workloads which aren't expected to be impacted, make a good
> effort at demonstrating that they are not impacted.
>
>- Perform stability/stress testing, publish results.
>
>Writing the code is about 5% of the effort for this sort of thing.
>
>Yes, we can toss it in the tree and see what happens. But it tends to be
>the case that unless someone does targetted testing such as the above,
>regressions simply aren't noticed for long periods of time. <wonders which
>schmuck gets to do the legwork when people report problems>
>
>Just the (unchangelogged) changes to the when-to-call-mark_page_accessed()
>logic are a big deal. Probably these should be a separate patch -
>separately changelogged, separately tested, separately justified.
>
>Performance testing is *everything* for this sort of patch and afaict none
>has been done, so it's as if it hadn't been written, no?
>-
>
>
>
Rik / Peter ... I lost the original mail + patch, but if you put it
up on a URL somewhere, Andy would probably run it through the test
harness for at least some basic perf testing, if you ask him ;-)
Probably against mainline, not -mm, as -mm seems to have other
problems right now.
M.
WARNING: multiple messages have this Message-ID (diff)
From: "Martin J. Bligh" <mbligh@mbligh.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Rik van Riel <riel@redhat.com>,
a.p.zijlstra@chello.nl, linux-mm@kvack.org, torvalds@osdl.org,
piggin@cyberone.com.au, linux-kernel@vger.kernel.org,
Andy Whitcroft <apw@shadowen.org>
Subject: Re: [PATCH] mm: use-once cleanup
Date: Thu, 27 Jul 2006 07:05:03 -0700 [thread overview]
Message-ID: <44C8C80F.8010705@mbligh.org> (raw)
In-Reply-To: <20060727011204.87033366.akpm@osdl.org>
>>Peter Zijlstra wrote:
>>
>>
>>>Hi,
>>>
>>>This is yet another implementation of the PG_useonce cleanup spoken of
>>>during the VM summit.
>>>
>>>
>>After getting bitten by rsync yet again, I guess it's time to insist
>>that this patch gets merged...
>>
>>Andrew, could you merge this? Pretty please? ;)
>>
>>
>>
>
>Guys, this is a performance patch, right?
>
>One which has no published performance testing results, right?
>
>It would be somewhat odd to merge it under these circumstances.
>
>And this applies to all of these
>hey-this-is-cool-but-i-didnt-bother-testing-it MM patches which people are
>throwing around. This stuff is *hard*. It has a bad tendency to cause
>nasty problems which only become known months after the code is merged.
>
>I shouldn't have to describe all this, but
>
>- Identify the workloads which it's supposed to improve, set up tests,
> run tests, publish results.
>
>- Identify the workloads which it's expected to damage, set up tests, run
> tests, publish results.
>
>- Identify workloads which aren't expected to be impacted, make a good
> effort at demonstrating that they are not impacted.
>
>- Perform stability/stress testing, publish results.
>
>Writing the code is about 5% of the effort for this sort of thing.
>
>Yes, we can toss it in the tree and see what happens. But it tends to be
>the case that unless someone does targetted testing such as the above,
>regressions simply aren't noticed for long periods of time. <wonders which
>schmuck gets to do the legwork when people report problems>
>
>Just the (unchangelogged) changes to the when-to-call-mark_page_accessed()
>logic are a big deal. Probably these should be a separate patch -
>separately changelogged, separately tested, separately justified.
>
>Performance testing is *everything* for this sort of patch and afaict none
>has been done, so it's as if it hadn't been written, no?
>-
>
>
>
Rik / Peter ... I lost the original mail + patch, but if you put it
up on a URL somewhere, Andy would probably run it through the test
harness for at least some basic perf testing, if you ask him ;-)
Probably against mainline, not -mm, as -mm seems to have other
problems right now.
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-07-27 14:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-17 20:40 [PATCH] mm: use-once cleanup Peter Zijlstra
2006-07-17 20:40 ` Peter Zijlstra
2006-07-27 7:48 ` Rik van Riel
2006-07-27 7:48 ` Rik van Riel
2006-07-27 8:12 ` Andrew Morton
2006-07-27 8:12 ` Andrew Morton
2006-07-27 14:05 ` Martin J. Bligh [this message]
2006-07-27 14:05 ` Martin J. Bligh
2006-07-27 14:44 ` Andy Whitcroft
2006-07-27 14:44 ` Andy Whitcroft
2006-07-28 15:34 ` Mel Gorman
2006-07-28 15:34 ` Mel Gorman
2006-07-28 16:57 ` Peter Zijlstra
2006-07-28 16:57 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44C8C80F.8010705@mbligh.org \
--to=mbligh@mbligh.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=piggin@cyberone.com.au \
--cc=riel@redhat.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.