First cut at hwpmc support on MIPS

George Neville-Neil gnn at neville-neil.com
Tue Feb 23 03:27:20 UTC 2010


On Feb 18, 2010, at 21:30 , Joseph Koshy wrote:

> 
>> Please review and let me know if you have comments.  I'd like to commit this
>> in a week or so.
> 
>> http://people.freebsd.org/~gnn/mipshwpmc_1.diff
> 
> Nice work!
> 

Thanks.

> Review comments, adding to those already commented on:
> 
> 1) There appears to be unnecessary gunk (UTF8?) in the manual page.
> 
> +.%B "MIPS32 24K Processor Core Family Software User<E2><80><99>s Manual"
> ...
> +to a D-cache miss. The LSU can signal a <E2><80><9C>long stall<E2><80><9D> on a D-cache
> 
> etc.
> 
> You could use .Bq, .Sq.  Plain ASCII quote marks would also work here.
> 

Fixed.

> 2) The manual page is missing a short description of the capabilities
>   of these PMCs.
> 

Fixed.


> 3) The code doesn't appear to support sampling; the manual page should
>   mention this.
> 

Fixed.

> 4) The debug printf() in mips_intr should be removed:
> 
> +static int
> +mips_intr(int cpu, struct trapframe *tf)
> +{
> +       printf("intr\n");
> +       return 0;
> +}
> 

Fixed.

> 5) It would be help to split "hwpmc_mips.c" into two files:
> 
>   - One for code specific to this PMC family.  Say "hwpmc_mips24k.c".
>   - One for "generic" MIPS related code, e.g.,
>     code to walk stacks.
> 
>   You should expect that every manufacturer will have their own kind
>   of PMCs, with differing capabilities and programming models.
> 
>   Catering for the variability upfront would be prudent.  As
>   commented on by earlier reviewers, you may want to consider
>   changing symbol naming to suit.
> 

This is partly fixed, in that I moved to using symbols with 24K but
I have not yet split the files.  Probably easier now than later, but
I'm not a huge fan of having the files proliferate for minor
changes.  I'm about to look at octeon and if I find that
sufficiently different I'll do the split.



> 6) These definitions will cause trouble on 64 bit MIPS systems:
> 
> +#define        PMCLOG_READADDR         PMCLOG_READ32
> +#define        PMCLOG_EMITADDR         PMCLOG_EMIT32
> 

Good point.

> 
> 7) From the definitions in the header file, these PMCs appear to
>   support the concept of sampling based on processor mode:
> 
> +#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 */
> 
>   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:
> 
> +static int
> +mips_allocate_pmc(enum pmc_event pe, char *ctrspec __unused,
> +                 struct pmc_op_pmcallocate *pmc_config __unused)
> +{
> +       switch (pe) {
> +       default:
> +               break;
> +       }
> +       
> +       return (0);
> +}
> 
> 

Is there any other processor that does this?  Right now I make the chip
sample in all modes by fiat.

> 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.
> 
> +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 */
> +};
> 
> +const struct mips_event_code_map mips_event_codes[] = {
> +       { PMC_EV_MIPS_CYCLE, 0, 0},
> +       { PMC_EV_MIPS_CYCLE, 1, 0},  <<<--- repeated information 
> 
> 
> 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:
> 
> +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 = config;
> 

Again, for both of these, is there an example I should work from?

> 
> 10) If the number and width of these PMCs are fixed, you should
>    document that in the manual page:
> 
> pmc_md_initialize()
> {
> +       mips_npmcs = 2;
> ...
> +       pcd->pcd_width = 32; /* XXX: Fix for 64 bit MIPS */
> 

Fixed.

Thanks for the feedback.  Get back to me on these last couple of issues and
I'll finish the clean up, send out a new patch and then eventually commit.

Best,
George



More information about the freebsd-embedded mailing list