Re: [PATCH 3/4] gcov: add gcov profiling infrastructure

[Amerigo Wang <xiyou.wangcong@gmail.com>]

On Fri, Jun 05, 2009 at 11:23:04AM +0200, Peter Oberparleiter wrote:
> Amerigo Wang wrote:
>> On Wed, Jun 03, 2009 at 05:26:22PM +0200, Peter Oberparleiter wrote:
>>> Peter Oberparleiter wrote:
>>>> Andrew Morton wrote:
>>>>> On Tue, 02 Jun 2009 13:44:02 +0200
>>>>> Peter Oberparleiter <oberpar@linux.vnet.ibm.com> wrote:
>>>>>> +	/* Duplicate gcov_info. */
>>>>>> +	active = num_counter_active(info);
>>>>>> +	dup = kzalloc(sizeof(struct gcov_info) +
>>>>>> +		      sizeof(struct gcov_ctr_info) * active, GFP_KERNEL);
>>>>> How large can this allocation be?
>>>> Hm, good question. Having a look at my test system, I see coverage 
>>>> data files of up to 60kb size. With counters making up the largest 
>>>> part of those, I'd guess the allocation size can be around ~55kb. I 
>>>> assume that makes it a candidate for vmalloc?
>>> A further run with debug output showed that the maximum size is
>>> actually around 4k, so in my opinion, there is no need to switch
>>> to vmalloc.
>>
>> Unless you want virtually continious memory, you don't need to
>> bother vmalloc().
>>
>> kmalloc() and get_free_pages() are all fine for this.
>
> kmalloc() requires contiguous pages to serve an allocation request  
> larger than a single page. The longer a kernel runs, the more fragmented  
> the pool of free pages gets and the probability to find enough  
> contiguous free pages is significantly reduced.
>
> In this case (having had a 3rd look), I found allocations of up to  
> ~50kb, so to be sure, I'll switch that particular allocation to 
> vmalloc().
>

Well, at least get_free_pages() is fine, 50Kb is about 16 pages on x86,
so the order is 4, not big for get_free_pages()...

And note that vmalloc() needs extra efforts to do page mapping...