On Fri, 05 Jun 2009 11:23:04 +0200 Peter Oberparleiter <oberpar@xxxxxxxxxxxxxxxxxx> wrote:
Amerigo Wang wrote:On Wed, Jun 03, 2009 at 05:26:22PM +0200, Peter Oberparleiter wrote: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.Peter Oberparleiter wrote:Unless you want virtually continious memory, you don't need toAndrew Morton wrote:A further run with debug output showed that the maximum size isOn Tue, 02 Jun 2009 13:44:02 +0200Hm, 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?
Peter Oberparleiter <oberpar@xxxxxxxxxxxxxxxxxx> wrote:
+ /* Duplicate gcov_info. */How large can this allocation be?
+ active = num_counter_active(info);
+ dup = kzalloc(sizeof(struct gcov_info) +
+ sizeof(struct gcov_ctr_info) * active, GFP_KERNEL);
actually around 4k, so in my opinion, there is no need to switch
to vmalloc.
bother vmalloc().
kmalloc() and get_free_pages() are all fine for this.
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, vmalloc() isn't magic. It can suffer internal fragmentation of
the fixed-sized virtual address arena.
Is it possible to redo the data structures so that the large array
isn't needed? Use a list, or move the data elsewhere or such?