Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 23 Jul 2007 22:10:45 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: -mm merge plans for 2.6.23 |
| |
Ray Lee wrote: > That said, I'm willing to run my day to day life through both a swap > prefetch kernel and a normal one. *However*, before I go through all > the work of instrumenting the damn thing, I'd really like Andrew (or > Linus) to lay out his acceptance criteria on the feature. Exactly what > *should* I be paying attention to? I've suggested keeping track of > process swapin delay total time, and comparing with and without. Is > that reasonable? Is it incomplete?
Um, isn't it up to you? The questions that need to be answered are:
1. What are you trying to achieve? Presumably you have some intended or desired effect you're trying to get. What's the intended audience? Who would be expected to see a benefit? Who suffers? 2. How does the code achieve that end? Is it nasty or nice? Has everyone who's interested in the affected areas at least looked at the changes, or ideally given them a good review? Does it need lots of tunables, or is it set-and-forget? 3. Does it achieve the intended end? Numbers are helpful here. 4. Does it make anything worse? A lot or a little? Rare corner cases, or a real world usage? Again, numbers make the case most strongly.
I can't say I've been following this particular feature very closely, but these are the fundamental questions that need to be dealt with in merging any significant change. And as Nick says, historically point 4 is very important in VM tuning changes, because "obvious" improvements have often ended up giving pathologically bad results on unexpected workloads.
J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |