[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090604090839.GB7030@cr0.nay.redhat.com>
Date: Thu, 4 Jun 2009 17:08:39 +0800
From: Amerigo Wang <xiyou.wangcong@...il.com>
To: Peter Oberparleiter <oberpar@...ux.vnet.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, andi@...stfloor.org,
ying.huang@...el.com, W.Li@....COM, michaele@....ibm.com,
mingo@...e.hu, heicars2@...ux.vnet.ibm.com,
mschwid2@...ux.vnet.ibm.com
Subject: Re: [PATCH 3/4] gcov: add gcov profiling infrastructure
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@...ux.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists