Date: Sun, 28 Feb 2010 18:04:18 -0500 From: George Neville-Neil <gnn@neville-neil.com> To: Joseph Koshy <jkoshy@freebsd.org> Cc: embedded@freebsd.org, fabient@freebsd.org Subject: Re: First cut at hwpmc support on MIPS Message-ID: <4FDD422C-DF35-4FFC-9D3F-77801574DCB9@neville-neil.com> In-Reply-To: <861vg54mr7.wl%koshy@unixconsulting.co.in> References: <42B59FCC-7A59-4383-BE4E-366B80B504BF@neville-neil.com> <867hqa9d0h.wl%koshy@unixconsulting.co.in> <3BF42672-9790-4D7F-9723-3D80601930B7@neville-neil.com> <861vg54mr7.wl%koshy@unixconsulting.co.in>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 28, 2010, at 06:36 , Joseph Koshy wrote:
>=20
>>> 7) =46rom the definitions in the header file, these PMCs appear to
>>> support the concept of sampling based on processor mode:
>>>=20
>>> +#define MIPS_PMC_USER_ENABLE 0x08 /* Count in USER =
mode */
>>> +#define MIPS_PMC_SUPER_ENABLE 0x04 /* Count in =
SUPERVISOR mode */
>>> +#define MIPS_PMC_KERNEL_ENABLE 0x02 /* Count in KERNEL =
mode */
>>>=20
>>> If that is the case, then you should support those modifiers in
>>> libpmc's event parsing. The libpmc code in the patch appears to be
>>> a stub:
>>>=20
>>> +static int
>>> +mips_allocate_pmc(enum pmc_event pe, char *ctrspec __unused,
>>> + struct pmc_op_pmcallocate *pmc_config __unused)
>>> +{
>>> + switch (pe) {
>>> + default:
>>> + break;
>>> + }
>>> + =20
>>> + return (0);
>>> +}
>>>=20
>>>=20
>> Is there any other processor that does this? Right now I make the =
chip
>> sample in all modes by fiat.
>=20
> All the Intel and AMD PMCs: see the handling of the "usr" and "os"
> qualifiers.
>=20
OK, done.
>>> 8) You can reduce the size of the following table in "hwpmc_mips.c",
>>> by treating the pe_counter field as a set of flags.
>>>=20
>>> +struct mips_event_code_map {
>>> + enum pmc_event pe_ev; /* enum value */
>>> + uint8_t pe_counter; /* Which counter this can be =
counted in. */
>>> + uint8_t pe_code; /* numeric code */
>>> +};
>>>=20
>>> +const struct mips_event_code_map mips_event_codes[] =3D {
>>> + { PMC_EV_MIPS_CYCLE, 0, 0},
>>> + { PMC_EV_MIPS_CYCLE, 1, 0}, <<<--- repeated information=20
>=20
> Most Intel CPUs have restrictions on the events that PMCs support.
> You may want to look at the P6, or Intel Core support code for =
examples.
>=20
>>> 9) You'd want to support flags that control counting based on
>>> processor modes. For this, you would want to pass down flags
>>> from userland and change the `pm_mips_evsel' field to suit:
>>>=20
>>> +static int
>>> +mips_allocate_pmc(int cpu, int ri, struct pmc *pm,
>>> + const struct pmc_op_pmcallocate *a)
>>> +{
>>> ...
>>> + pm->pm_md.pm_mips.pm_mips_evsel =3D config;
>>>=20
>=20
>> Again, for both of these, is there an example I should work from?
>=20
> See P6, Pentium IV, AMD, Intel Core for examples.
>=20
Done.
> Additional comments on patch #3:
>=20
> * The manual page still has UTF 8. E.g.,-
> +Count all pipeline bubbles that are a result of multicycle ISPRAM
> +access. Pipeline bubbles are defined as all cycles that IFU =
doesn<E2><80><99>t
> +present an instruction to ALU. The four cycles after a redirect are
> * The convention is that sentences always start on a new line in
> -mdoc input.
Fixed.
Thanks,
George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FDD422C-DF35-4FFC-9D3F-77801574DCB9>