From: t.fujak@samsung.com (Tomasz Fujak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 1/1] Extended events (platform-specific) support in perf
Date: Fri, 22 Jan 2010 14:08:35 +0100 [thread overview]
Message-ID: <034a01ca9b64$01863d10$0492b730$%fujak@samsung.com> (raw)
In-Reply-To: <20100122122607.GE1244@ghostprotocols.net>
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-
> kernel-bounces at lists.infradead.org] On Behalf Of Arnaldo Carvalho de
> Melo
> Sent: Friday, January 22, 2010 1:26 PM
> To: Tomasz Fujak
> Cc: jpihet at mvista.com; peterz at infradead.org; p.osciak at samsung.com;
> jamie.iles at picochip.com; will.deacon at arm.com; linux-
> kernel at vger.kernel.org; kyungmin.park at samsung.com; mingo at elte.hu;
> linux-arm-kernel at lists.infradead.org; m.szyprowski at samsung.com
> Subject: Re: [PATCH v1 1/1] Extended events (platform-specific) support
> in perf
>
> Em Fri, Jan 22, 2010 at 01:08:59PM +0100, Tomasz Fujak escreveu:
> > Signed-off-by: Tomasz Fujak <t.fujak@samsung.com>
> > Reviewed-by: Pawel Osciak <p.osciak@samsung.com>
> > Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Reviewed-by: Kyungmin Park <kuyngmin.park@samsung.com>
>
> "Extended" seems vague, I think in this context "platform_" would be a
> better namespace specifier.
Right.
> > +#define BYTES_PER_CHUNK 4096
> > +/* returns the number of lines read;
> > + on fail the return is negative and no memory is allocated
> > + otherwise the *buf contains a memory chunk of which first
> > + *size bytes are used for file contents
> > + */
> > +static int read_file(int fd, char **buf, unsigned *size)
> > +{
> > + unsigned bytes = BYTES_PER_CHUNK;
> > + int lines = 0;
> > + char *ptr = malloc(bytes);
>
> malloc can fail... Also why is that you can't process the lines one by
> one instead of reading the whole (albeit small) file at once?
Right, no malloc check.
The purpose of not processing line-by-line is that then the collection needs
to be dynamic.
Since the file buffer gets dropped after it's processed, the overallocated
memory is returned to the system.
In case of the collection (here an array and a counter) it'd require tricks
not to overallocate, and still be O(#events).
But you're right I didn't do it right - in case the a line does not parse,
memory reserved for it is not freed. Fixing.
> > +
> > + if (name && description) {
> > + symbols[count].symbol = name;
> > + symbols[count].alias = "";
> > + ++count;
> > + /* description gets lost here */
> > + free(description);
> > + } else {
> > + free(description);
> > + free(name);
> > + }
>
> Having "free(description);" in both cases seems funny :-)
I wasn't so bold as to upgrade the perf with human-readable event
description.
Otherwise yes, moving it outside.
>
> - Arnaldo
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2010-01-22 13:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-22 12:08 [PATCH/RFC v1 0/1] Platform-specific event support in the perf Tomasz Fujak
2010-01-22 12:08 ` [PATCH v1 1/1] Extended events (platform-specific) support in perf Tomasz Fujak
2010-01-22 12:26 ` Arnaldo Carvalho de Melo
2010-01-22 13:08 ` Tomasz Fujak [this message]
2010-01-27 11:35 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='034a01ca9b64$01863d10$0492b730$%fujak@samsung.com' \
--to=t.fujak@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox