On Mon, May 13, 2013 at 08:43:36AM -0700, Dan Magenheimer wrote:
The above appears to be a new addition to my original zbud design.
While it may appear to be a good idea for improving LRU-ness, I
suspect it may have unexpected side effects in that I think far
fewer "fat" zpages will be buddied, which will result in many more
unbuddied pages containing a single fat zpage, which means much worse
overall density on many workloads.
Yes, I see what you are saying. While I can't think of a workload that would
cause this kind of allocation pattern in practice, I also don't have a way to
measure the impact this first-fit fast path code has on density.
This may not be apparent in kernbench or specjbb or any workload
where the vast majority of zpages compress to less than PAGE_SIZE/2,
but for a zsize distribution that is symmetric or "skews fat",
it may become very apparent.
I'd personally think it should be kept because 1) it makes a fast allocation
path and 2) improves LRU locality. But, without numbers to demonstrate a
performance improvements or impacts on density, I wouldn't be opposed to taking
it out if it is a point of contention.
Anyone else care to weigh in?