Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755690AbZFEJXq (ORCPT ); Fri, 5 Jun 2009 05:23:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752311AbZFEJXi (ORCPT ); Fri, 5 Jun 2009 05:23:38 -0400 Received: from mtagate7.uk.ibm.com ([195.212.29.140]:42804 "EHLO mtagate7.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750890AbZFEJXh (ORCPT ); Fri, 5 Jun 2009 05:23:37 -0400 Message-ID: <4A28E3F8.5050908@linux.vnet.ibm.com> Date: Fri, 05 Jun 2009 11:23:04 +0200 From: Peter Oberparleiter User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Amerigo Wang CC: Andrew Morton , linux-kernel@vger.kernel.org, andi@firstfloor.org, ying.huang@intel.com, W.Li@Sun.COM, michaele@au1.ibm.com, mingo@elte.hu, heicars2@linux.vnet.ibm.com, mschwid2@linux.vnet.ibm.com Subject: Re: [PATCH 3/4] gcov: add gcov profiling infrastructure References: <20090602114359.129247921@linux.vnet.ibm.com> <20090602114402.951631599@linux.vnet.ibm.com> <20090602150324.c706b1d2.akpm@linux-foundation.org> <4A266546.5080601@linux.vnet.ibm.com> <4A26961E.7040207@linux.vnet.ibm.com> <20090604090839.GB7030@cr0.nay.redhat.com> In-Reply-To: <20090604090839.GB7030@cr0.nay.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1689 Lines: 37 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 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(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/