| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 27 Jul 2006 15:44:53 +0100 From: Andy Whitcroft <apw@...dowen.org> To: "Martin J. Bligh" <mbligh@...igh.org> CC: Andrew Morton <akpm@...l.org>, Rik van Riel <riel@...hat.com>, a.p.zijlstra@...llo.nl, linux-mm@...ck.org, torvalds@...l.org, piggin@...erone.com.au, linux-kernel@...r.kernel.org Subject: Re: [PATCH] mm: use-once cleanup Martin J. Bligh wrote: > >>> 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. I'll happily run it through the test suites once I get my machines working again after 2.6.18-rc2-mm1 has finished with them :(. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists