On Mon, 20 Feb 2006, Bryce Harrington wrote: > On Fri, Feb 17, 2006 at 07:22:27PM +0000, Mel Gorman wrote: >> On Fri, 17 Feb 2006, Bryce Harrington wrote: >>> On Fri, Feb 17, 2006 at 11:03:43AM +0000, Mel Gorman wrote: >>>>> By chance do you have a web or ftp site where these patches are posted? >>>> >>>> I didn't, but I do now. >>>> >>>> list-based anti-fragmentation >>>> o http://www.csn.ul.ie/~mel/projects/patches/brokenout/mbuddy/v22 >>>> o Full patch is called full-mbuddy-v22.diff >>>> zone-based anti-fragmentation >>>> o http://www.csn.ul.ie/~mel/projects/patches/brokenout/zbuddy/v5 >>>> o Full patch is called zbuddy-v5-full.diff >>> >>> Great, thanks! >>> >> >> Thank you for picking them up. >> >> Great. They will always be in a vN directory where N is the number of >> release. > > One request regarding file names - our tools key off of the patch name > to determine which kernel to apply against. Would it be possible for > you to create symlinks to the patch that include the kernel or kernels > you'd like to test against? I.e., to test zbuddy-v5 against multiple > 2.6.16-rc3 kernels, something like: > > .../zbuddy/v5/ > 2.6.16-rc3-zbuddy-v5 -> zbuddy-v5-full.diff > 2.6.16-rc3-mm1-zbuddy-v5 -> zbuddy-v5-full.diff > 2.6.16-rc3-mm2-zbuddy-v5 -> zbuddy-v5-full.diff > 2.6.16-rc3-mm3-zbuddy-v5 -> zbuddy-v5-full.diff > Ok, that's done now. In general, there will only be two kernels of interest. The mainline kernel at the time the patch was published and the latest -mm kernel. > Or alternately if you're only interested in results of your patch > against a specific kernel, if you include that kernel id in the patch > name itself, we can parse it from that. (This is what the nfsv4 guys > do. c.f. http://www.citi.umich.edu/projects/nfsv4/linux/kernel-patches/) > >>> Also, if you know of any regression or performance tests that you'd find >>> useful to have run automatically for anti-fragmentation (or other >>> memory-related aspects), I could work on setting those up to run on x86, >>> and later x86_64 and ia64. >>> >> >> The tests I always run are posted with each patch. On VMRegress, they >> correspond to bench-kbuild, bench-aim9, bench-stresshighalloc, >> bench-hugetlbcap and more recently bench-hotremovecap. However, I'm >> interested in any performance figures or reports you are willing to >> generate on as many platforms as possible. > > Ah, excellent, I probably will have a chance to start looking into this > in April (March is looking pretty conference-heavy for me.) We've done > automated vmregress runs for things before, although I personally > haven't set up modules with it. Looks fairly straightforward though; > I'll check back in if I have questions once I have some time to tinker > with it. > When you start looking into it, get back to me and I'll give a brief update on any test of interest in there. The documentation is virtually non-existant so figuring out what is useful in there is probably not the easiest job in the world :/ Thanks. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab
