Messages in this thread | | | Date | Fri, 05 Jun 2009 11:23:04 +0200 | From | Peter Oberparleiter <> | Subject | Re: [PATCH 3/4] gcov: add gcov profiling infrastructure |
| |
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().
| |