Re: [PATCH 0/3] Lumpy Reclaim V5
Andrew Morton wrote: > On Mon, 12 Mar 2007 18:22:45 + Andy Whitcroft <[EMAIL PROTECTED]> wrote: > >> Following this email are three patches which represent the >> current state of the lumpy reclaim patches; collectively lumpy V5. > > So where do we stand with this now?Does it make anything get better? I am still working to fairly compare the various combinations. One of the problems is that if you push any reclaim algorithm to its physical limits you will get the same overall success rates. I think there is still some work to do refining lumpy, and reclaim in general. But I feel what we have now is pretty solid base for that. > I (continue to) think that if this is to be truly useful, we need some way > of using it from kswapd to keep a certain minimum number of order-1, > order-2, etc pages in the freelists. I think this is a key component of the mix and am just starting to play with this. I hope that this can provide improvements in the instantaneous availability of these higher orders and improve average latency. -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Lumpy Reclaim V5
On Mon, 12 Mar 2007 18:22:45 + Andy Whitcroft <[EMAIL PROTECTED]> wrote: > Following this email are three patches which represent the > current state of the lumpy reclaim patches; collectively lumpy V5. So where do we stand with this now?Does it make anything get better? I (continue to) think that if this is to be truly useful, we need some way of using it from kswapd to keep a certain minimum number of order-1, order-2, etc pages in the freelists. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Lumpy Reclaim V5
Following this email are three patches which represent the current state of the lumpy reclaim patches; collectively lumpy V5. This patch kit is against 2.6.21-rc3-mm2. This stack is split out to show the incremental changes in this version. This contains one fixup following on from Christoph Lameters feedback and one change affecting scan rates. Andrew, please consider for -mm. Comparitive testing between lumpy-V4 and lump-V5 generally shows a small improvement, coming from the slight increase in scanning coming from second of the patches. I have taken the lumpy-V3 patches and the last batch of changes and folded them back into a single patch (collectively lumpy-V4), updating attribution. On top of this are are two patches the first the result of feedback from Christoph and the latter a change which I believe is a correctness issue for scanning rates: lumpy-reclaim-V4: folded back base, changes incorporated are listed in the changelog which is included in the patch. lumpy-back-out-removal-of-active-check-in-isolate_lru_pages: reinstating a BUG where the active state missmatched the lru we are scanning. As pointed out by Christoph Lameter, there should not be a missmatch and testing confirms with this base there are none. lumpy-only-count-taken-pages-as-scanned: when scanning an area around a target page taken from the LRU we will only take pages which match the active state. Previously we would count the missmatching pages passed over as 'scanned'. Prior to lumpy a page was only counted as 'scanned' if we had removed it from the LRU and reclaimed or rotated it back to the list. This leads to reduced reclaim scanning and affects reclaim performance. Move to counting pages as scanned only when actually touched. Against: 2.6.21-rc3-mm2 -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
