[Top] [All Lists]

Re: [PATCH v5 3/5] MIPS: perf: Reorganize contents of perf support files

To: David Daney <>
Subject: Re: [PATCH v5 3/5] MIPS: perf: Reorganize contents of perf support files.
From: Deng-Cheng Zhu <>
Date: Mon, 26 Sep 2011 17:12:31 +0800
Cc:, David Daney <>,, Peter Zijlstra <>, Paul Mackerras <>, Ingo Molnar <>, Arnaldo Carvalho de Melo <>, Dezhong Diao <>, Gabor Juhos <>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qVweLBTZQWwnkfg5ImwzuEs+CkUWZ/2wmtmfFfYfInM=; b=Zj4nx4bv0itKgIGXJGP4b0ale61K6QL/s7VjU1DpBtnvGf+mg2yVQtvbo8IA2RRO6W fR5RZVD8pf9/bL/BoQAg5XKfPeI7wkzsgaRjjZA0cjKisT0i5TK8abvXeoEKlImEOSU9 Y1RiMEqS8iPT391i6BJuy/Qa+muAYb4/UDoXc=
In-reply-to: <>
References: <> <> <> <>
2011/9/25 David Daney <>:
> On 09/23/2011 07:50 PM, Deng-Cheng Zhu wrote:
>> 2011/9/23 David Daney<>
>>> The contents of arch/mips/kernel/perf_event.c and
>>> arch/mips/kernel/perf_event_mipsxx.c were divided in a seemingly ad
>>> hoc manner, with the first including the second.
>>> I moved all the hardware counter support code to perf_event_mipsxx.c
>>> and removed the gating #ifdefs to the Kconfig and Makefile.
>>> Now perf_event.c contains only the callchain support, everything else
>>> is in perf_event_mipsxx.c
>> Sorry for my late comment. I personally don't think it's a bad idea to
>> use the original gating #ifdefs, because it allows sharing common code
>> among different types of MIPS PMUs. Also, using CPU types as compiling
>> conditions seems make sense. If you move the common hunk to
>> perf_event_mipsxx.c, other CPUs like loognson series will have to
>> duplicate
>> these stuff.
> I disagree, and here is why:
> Almost all the the code is mipsxx specific.
> If Loongson has a PMU that can reuse this code, it can just be added to
> perf_event_mipsxx.c along with all the other mips compatible PMUs
> If this is not feasible, then it can have its own file and and common code
> can be removed to a common place at that time.
> In any event, I have not seen any Loongson PMU patches, if someone has such
> patches I would be happy to consider changes that would make the kernel as a
> whole cleaner.  But preventing cleanup and removal of a ton of #ifdefery in
> hope that Loongson patches may someday want something different is not what
> I would call a good way forward.

[DC]: Here's a patch set to support Loongson2 sent by Wu Zhangjin based on
MIPS Perf-events v2:

It used the "skeleton code (perf_event.c) + PMU specific code
(perf_event_$PMU.c)" model. The current perf_event.c is right the place
you mentioned as "a common place" to accommodate common code.

The naming convention here came from the current Oprofile code which
contains op_model_mipsxx.c, op_model_loongson2.c and op_model_rm9000.c. I
think it will confuse people if we put Loongson perf code into


<Prev in Thread] Current Thread [Next in Thread>