Re: [Lhms-devel] [RFC] buddy allocator without bitmap [2/4]

[Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>]

Dave Hansen wrote:
>>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 <kamezawa.hiroyu@jp.fujitsu.com>

--
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>