On 06/29/2011 03:28 PM, Xiao Guangrong wrote:
On 06/29/2011 08:18 PM, Avi Kivity wrote:
> On 06/29/2011 02:50 PM, Xiao Guangrong wrote:
>> >> >
>> >> > I think we should do this unconditionally. The cost of
ping-ponging the shared cache line containing reader_counter will increase with large smp
counts. On the other hand, zap_page is very rare, so it can be a little slower. Also, less
code paths = easier to understand.
>> >> >
>> >>
>> >> On soft mmu, zap_page is very frequently, it can cause performance
regression in my test.
>> >
>> > Any idea what the cause of the regression is? It seems to me that
simply deferring freeing shouldn't have a large impact.
>> >
>>
>> I guess it is because the page is freed too frequently, i have done the
test, it shows
>> about 3219 pages is freed per second
>>
>> Kernbench performance comparing:
>>
>> the origin way: 3m27.723
>> free all shadow page in rcu context: 3m30.519
>
> I don't recall seeing such a high free rate. Who is doing all this zapping?
>
> You may be able to find out with the function tracer + call graph.
>
I looked into it before, it is caused by "write flood" detected, i also noticed
some pages are zapped and allocation again and again, maybe we need to improve
the algorithm of detecting "write flood".
Ok. Let's drop the two paths, and put this improvement on the TODO instead.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
