Messages in this thread |  | | | Subject | Re: [PATCH 3/4] gcov: add gcov profiling infrastructure | | From | Michael Ellerman <> | | Date | Thu, 04 Jun 2009 02:01:03 +1000 |
| |
On Wed, 2009-06-03 at 17:26 +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.
The real question is how big can active be, and it looks like <= 5 is the answer:
+/* Determine number of active counters. Based on gcc magic. */ +static unsigned int num_counter_active(struct gcov_info *info) +{ + unsigned int i; + unsigned int result = 0; + + for (i = 0; i < GCOV_COUNTERS; i++) { + if (counter_active(info, i)) + result++; + } + return result; +} +#define GCOV_COUNTERS 5
So that seems reasonable.
I assumed these were the per BB counters, but it seems they're counter _types_. Where are the BB counters, in the values array? If so perhaps that is the candidate for vmalloc.
cheers [unhandled content-type:application/pgp-signature] |  |