Dave Hansen wrote:

quoted

To Dave:
cost of prefetch() is not here, because I found it is very sensitive to
what is done in the loop and difficult to measure in this program.
I found cost of calling prefetch is a bit high, I'll measure whether
prefetch() in buddy allocator is good or bad again.

I think this result shows I should use non-atomic ops when I can.

I think we all know that locked instructions are going to be slower. 
However, what I wanted to see is how it influences a slightly more
realistic test, and actually in the context of the kernel.  Let's
actually see how much impact using the prefetch() and atomic vs
non-atomic ops has when they're used *in* the kernel on a less
contrived  less microbenchmarky test.

How about finding some kind of benchmark that will do a bunch of forking
and a bunch of page faulting to cause lots of activity in the allocator?

I cannot find suitable one, so I test in microbenchmark calling mmap()
and munmap(). As you say, real-world workload test is more suitable to
measure kernel's performance.

I'd suggest something like http://ck.kolivas.org/kernbench/ or SDET if
you can get your hands on it.  Anybody else have some suggestions?

thanks.

The atomic ops, you're probably right about, but it would still be nice
to have some hard data.  As for prefetch(), we could scatter it and
unlikely() all over the kernel, but we only tend to do so when we can
either demonstrate a concrete gain, or it is a super-hot path.  With
hot-and-cold-pages around, even the allocator functions don't
necessarily count as super-hot.  

Hmm, my test program was mmap()/munnamp Magebytes of page and hot_cold_page()
does not work enough, because current batch is16.
My test might be a bit special case.


-- Kame

-- 
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki [off-list ref]

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>