Hi,Stephane.
I have been tracing your work in perfmon2/3,and doing some similar work in my
thesis.
I extended the task_struct with pmu-related context and added support to
save/restore it in __switch_to,all under linux 2.6.30.
Then I encounter a problem, when the following code is running with counting
disabled.
...
{
wrmsrl(pmu_reg->counter_addr,pmu_reg->counter);
rdmsrl(pmu_reg->counter_addr,co);
}
so far what really confusing is that quite often values of pmu_reg->counter and
co are not equal，and the later one would suddenly become really large（e.g. the
high 8 bits of counter register are ff），i.e. the value written into counter
register is wrong
Then, I modified the code to the following version, like
{
again:
wrmsrl(pmu_reg->counter_addr,pmu_reg->counter & PMUC_MASK);
rdmsrl(pmu_reg->counter_addr,co);
if(pmu_reg->counter!=co)
goto again;
}
This time, the system runs into a state of unhalted busy with no reaction and
no oops printing.
And why? I know you shoule be familiar with these issues, so could any help?
Thank you!
Yours,
Jie Ying @ USTC
> -----Original E-mail-----
> From: [email protected]
> Sent Time: 2009-12-16 7:58:51
> To: [email protected]
> Cc:
> Subject: perfmon2-devel Digest, Vol 26, Issue 9
>
> Send perfmon2-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of perfmon2-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Question about the plm field in perf_event_attr
> (Corey Ashford)
> 2. Re: Question about the plm field in perf_event_attr
> (stephane eranian)
> 3. Re: About PMC Save and Restore (stephane eranian)
> 4. About PMC Save and Restore (Jiaqing Du)
> 5. Re: Question about the plm field in perf_event_attr
> (stephane eranian)
> 6. Re: Question about the plm field in perf_event_attr
> (Corey Ashford)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 14 Dec 2009 15:09:17 -0800
> From: Corey Ashford <[email protected]>
> Subject: Re: [perfmon2] Question about the plm field in
> perf_event_attr
> To: [email protected]
> Cc: Philip Mucci <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
> stephane eranian wrote:
> > Corey,
> >
> > Ok, so I tried what we talked about on a couple of
> > examples (some made up). And now here is what
> > I get:
> >
> > $ task -euops_issued:any,l2_ifetch:mesi date
> >
> > [0x513f0e event_sel=0xe umask=0x3f os=0 usr=1 en=1 int=1 inv=0 edge=0
> > cnt_mask=0] UOPS_ISSUED
> > FSTR=UOPS_ISSUED2:PORT0:PORT1:PORT2:PORT3:PORT4:PORT5:k=0:u=1:e=0:i=0:c=0
> >
> > [0x514f28 event_sel=0x28 umask=0x4f os=0 usr=1 en=1 int=1 inv=0 edge=0
> > cnt_mask=0] L2_IFETCH
> > FSTR=L2_IFETCH:SELF:I_STATE:S_STATE:E_STATE:M_STATE:k=0:u=1:e=0:i=0:c=0
> >
> > That looks like what you suggested. This is all handled in X86 code.
> > Hard to make it more specific than that!
>
> Yes, this is great :-) I can't see needing anything other than this right
> now.
>
> Perhaps in an initial port of an arch to libpfm4, fstr would just be a copy
> of
> str (or perhaps NULL to specify unimplemented). Later the reverse
> translation
> can be added.
>
> One question about the above example: I see usr=1... I assume the "task"
> program
> is passing in plm=<value for user mode> ?
>
> About the event aliases in the previous posting, wouldn't it be the case that
> having such aliases could cause an explosion in the number of events (mostly
> aliases) in the event table, since many events might need such variants?
>
> --
> Regards,
>
> - Corey
>
> Corey Ashford
> Software Engineer
> IBM Linux Technology Center, Linux Toolchain
> Beaverton, OR
> 503-578-3507
> [email protected]
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Dec 2009 10:13:54 +0100
> From: stephane eranian <[email protected]>
> Subject: Re: [perfmon2] Question about the plm field in
> perf_event_attr
> To: Corey Ashford <[email protected]>
> Cc: Philip Mucci <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Dec 15, 2009 at 12:09 AM, Corey Ashford
> <[email protected]> wrote:
> >
> >
> > stephane eranian wrote:
> >>
> >> Corey,
> >>
> >> Ok, so I tried what we talked about on a couple of
> >> examples (some made up). And now here is what
> >> I get:
> >>
> >> $ task -euops_issued:any,l2_ifetch:mesi date
> >>
> >> [0x513f0e event_sel=0xe umask=0x3f os=0 usr=1 en=1 int=1 inv=0 edge=0
> >> cnt_mask=0] UOPS_ISSUED
> >> FSTR=UOPS_ISSUED2:PORT0:PORT1:PORT2:PORT3:PORT4:PORT5:k=0:u=1:e=0:i=0:c=0
> >>
> >> [0x514f28 event_sel=0x28 umask=0x4f os=0 usr=1 en=1 int=1 inv=0 edge=0
> >> cnt_mask=0] L2_IFETCH
> >> FSTR=L2_IFETCH:SELF:I_STATE:S_STATE:E_STATE:M_STATE:k=0:u=1:e=0:i=0:c=0
> >>
> >> That looks like what you suggested. This is all handled in X86 code.
> >> Hard to make it more specific than that!
> >
> > Yes, this is great :-) ?I can't see needing anything other than this right
> > now.
> >
> > Perhaps in an initial port of an arch to libpfm4, fstr would just be a copy
> > of str (or perhaps NULL to specify unimplemented). ?Later the reverse
> > translation can be added.
>
> Yes, that would be fine.
>
> >
> > One question about the above example: I see usr=1... I assume the "task"
> > program is passing in plm=<value for user mode> ?
> >
> That is the effect of dfl_plm.
>
> > About the event aliases in the previous posting, wouldn't it be the case
> > that having such aliases could cause an explosion in the number of events
> > (mostly aliases) in the event table, since many events might need such
> > variants?
> >
> Based on the X86 situation, I don't think so. The event table contains
> primarily a clone of the documented event table as publish by the HW
> vendors. In the case of Intel, some events are clearly documented as
> requiring some modifiers to be set to specific values. For other events,
> it is suggested that if certain modifiers are turned on, then a different
> metric can be measured. Finally they are common metrics, i.e., events
> with modifiers what are used very frequently and therefore justify adding
> their alias to the table (as opposed to having to type the whole thing each
> time).
>
> So overall, I don't think this would contribute to the explosion in the number
> of entries in the table. Hopefully, the situation is similar on Power and your
> new CPU.
>
> > --
> > Regards,
> >
> > - Corey
> >
> > Corey Ashford
> > Software Engineer
> > IBM Linux Technology Center, Linux Toolchain
> > Beaverton, OR
> > 503-578-3507
> > [email protected]
> >
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 15 Dec 2009 15:29:06 +0100
> From: stephane eranian <[email protected]>
> Subject: Re: [perfmon2] About PMC Save and Restore
> To: Jiaqing Du <[email protected]>
> Cc: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Dec 15, 2009 at 3:10 PM, Jiaqing Du <[email protected]> wrote:
> > Hi Stephane,
> >
> > I found the following comment in your code:
> >
> >
> > pfm_core_restore_pmcs() at perfmon_intel_core.c
> >
> >
> > 488 ? ? /*
> > 489 ? ? ?* must restore DS pointer before restoring PMCs
> > 490 ? ? ?* as this can potentially reactivate monitoring
> > 491 ? ? ?*/
> > 492 ? ? if (ctx_arch->ds_area)
> > 493 ? ? ? ? wrmsrl(MSR_IA32_DS_AREA, (unsigned long)ctx_arch->ds_area);
> > 494
> > 495 ? ? for_each_bit(i, cast_ulp(set->used_pmcs), PFM_CORE_NUM_PMCS)
> > 496 ? ? ? ? wrmsrl(pfm_pmu_conf->pmc_desc[i].hw_addr, set->pmcs[i]);
> >
> >
> > What do you mean this can potentially reactivate monitoring? I met
> > some strange problems when I save and restore PMCs. Although I
> > disabled performance monitoring by clearing the enable bit in PMD,
> > still sometimes some PMCs overflowed after I restored them. I'm not
> > sure if they really overflowed, but at least I saw NMIs occurred
> > later. So in your comment, do you mean the similar problem?
> >
> PMD are data registers, they don't control start/stop. That all
> handled through the PMC registers.
>
> The comment is about the fact that the PEBS buffer area must
> be re-installed BEFORE you restore the PMC registers as they
> may be actively monitoring (enable bit set) and thus they may
> generate PEBS samples right away.
>
> Normally with perfmon, you leave the enable bit set in the
> PMC and you use pfm_start()/pfm_stop() to activate monitoring.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 15 Dec 2009 15:10:55 +0100
> From: Jiaqing Du <[email protected]>
> Subject: [perfmon2] About PMC Save and Restore
> To: [email protected]
> Cc: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Stephane,
>
> I found the following comment in your code:
>
>
> pfm_core_restore_pmcs() at perfmon_intel_core.c
>
>
> 488 /*
> 489 * must restore DS pointer before restoring PMCs
> 490 * as this can potentially reactivate monitoring
> 491 */
> 492 if (ctx_arch->ds_area)
> 493 wrmsrl(MSR_IA32_DS_AREA, (unsigned long)ctx_arch->ds_area);
> 494
> 495 for_each_bit(i, cast_ulp(set->used_pmcs), PFM_CORE_NUM_PMCS)
> 496 wrmsrl(pfm_pmu_conf->pmc_desc[i].hw_addr, set->pmcs[i]);
>
>
> What do you mean this can potentially reactivate monitoring? I met
> some strange problems when I save and restore PMCs. Although I
> disabled performance monitoring by clearing the enable bit in PMD,
> still sometimes some PMCs overflowed after I restored them. I'm not
> sure if they really overflowed, but at least I saw NMIs occurred
> later. So in your comment, do you mean the similar problem?
>
>
>
> Thanks,
> Jiaqing
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 15 Dec 2009 23:49:13 +0100
> From: stephane eranian <[email protected]>
> Subject: Re: [perfmon2] Question about the plm field in
> perf_event_attr
> To: Corey Ashford <[email protected]>
> Cc: Philip Mucci <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> Corey,
>
> We still need to settle on the user interface to extract default
> information (and maybe aliases information).
>
> Here is what I have today:
>
> typedef struct {
> const char *name;
> const char *desc;
> const char *alias;
> pfm_pmu_t pmu;
> int idx;
> int nattrs;
> int size;
> uint64_t code;
> struct {
> int is_alias:1;
> int reserved:31;
> };
> uint64_t reserved[9];
> } pfm_event_info_t;
>
> typedef struct {
> const char *name;
> const char *desc;
> const char *alias;
> pfm_attr_t type;
> struct {
> int is_dfl:1; /* is default */
> int is_alias:1;
> int reserved:30;
> };
> int idx;
> int size;
> uint64_t code;
> union {
> uint64_t dfl_val64;
> const char *dfl_str;
> int dfl_bool;
> int dfl_int;
> };
> uint64_t reserved1[6];
> } pfm_event_attr_info_t;
>
> int pfm_get_event_info(int idx, pfm_event_info_t *info);
> int pfm_get_event_attr_info(int idx, int attr_idx, pfm_event_attr_info_t
> *info);
>
>
> Notice the new is_alias and the alias string which is valid only if is_alias
> is set. it contains the event string describing how the alias build on the
> original event, e.g., with hardwired modifiers.
>
>
> On Tue, Dec 15, 2009 at 12:09 AM, Corey Ashford
> <[email protected]> wrote:
> >
> >
> > stephane eranian wrote:
> >>
> >> Corey,
> >>
> >> Ok, so I tried what we talked about on a couple of
> >> examples (some made up). And now here is what
> >> I get:
> >>
> >> $ task -euops_issued:any,l2_ifetch:mesi date
> >>
> >> [0x513f0e event_sel=0xe umask=0x3f os=0 usr=1 en=1 int=1 inv=0 edge=0
> >> cnt_mask=0] UOPS_ISSUED
> >> FSTR=UOPS_ISSUED2:PORT0:PORT1:PORT2:PORT3:PORT4:PORT5:k=0:u=1:e=0:i=0:c=0
> >>
> >> [0x514f28 event_sel=0x28 umask=0x4f os=0 usr=1 en=1 int=1 inv=0 edge=0
> >> cnt_mask=0] L2_IFETCH
> >> FSTR=L2_IFETCH:SELF:I_STATE:S_STATE:E_STATE:M_STATE:k=0:u=1:e=0:i=0:c=0
> >>
> >> That looks like what you suggested. This is all handled in X86 code.
> >> Hard to make it more specific than that!
> >
> > Yes, this is great :-) ?I can't see needing anything other than this right
> > now.
> >
> > Perhaps in an initial port of an arch to libpfm4, fstr would just be a copy
> > of str (or perhaps NULL to specify unimplemented). ?Later the reverse
> > translation can be added.
> >
> > One question about the above example: I see usr=1... I assume the "task"
> > program is passing in plm=<value for user mode> ?
> >
> > About the event aliases in the previous posting, wouldn't it be the case
> > that having such aliases could cause an explosion in the number of events
> > (mostly aliases) in the event table, since many events might need such
> > variants?
> >
> > --
> > Regards,
> >
> > - Corey
> >
> > Corey Ashford
> > Software Engineer
> > IBM Linux Technology Center, Linux Toolchain
> > Beaverton, OR
> > 503-578-3507
> > [email protected]
> >
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 15 Dec 2009 15:58:30 -0800
> From: Corey Ashford <[email protected]>
> Subject: Re: [perfmon2] Question about the plm field in
> perf_event_attr
> To: [email protected]
> Cc: Philip Mucci <[email protected]>,
> "[email protected]"
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
>
> stephane eranian wrote:
> > Corey,
> >
> > We still need to settle on the user interface to extract default
> > information (and maybe aliases information).
> >
> > Here is what I have today:
> >
> > typedef struct {
> > const char *name;
> > const char *desc;
> > const char *alias;
> > pfm_pmu_t pmu;
> > int idx;
> > int nattrs;
> > int size;
> > uint64_t code;
> > struct {
> > int is_alias:1;
> > int reserved:31;
> > };
> > uint64_t reserved[9];
> > } pfm_event_info_t;
> >
>
> You could get rid of is_alias if .alias doubled as a sentinel: alias points
> to
> an event name string if this event is an alias, and is NULL otherwise.
>
> > typedef struct {
> > const char *name;
> > const char *desc;
> > const char *alias;
> > pfm_attr_t type;
> > struct {
> > int is_dfl:1; /* is default */
> > int is_alias:1;
> > int reserved:30;
> > };
> > int idx;
> > int size;
> > uint64_t code;
> > union {
> > uint64_t dfl_val64;
> > const char *dfl_str;
> > int dfl_bool;
> > int dfl_int;
> > };
> > uint64_t reserved1[6];
> > } pfm_event_attr_info_t;
> >
> > int pfm_get_event_info(int idx, pfm_event_info_t *info);
> > int pfm_get_event_attr_info(int idx, int attr_idx, pfm_event_attr_info_t
> > *info);
> >
> >
> > Notice the new is_alias and the alias string which is valid only if is_alias
> > is set. it contains the event string describing how the alias build on the
> > original event, e.g., with hardwired modifiers.
>
> You could get rid of is_alias here too.
>
> I'm not convinced it's necessary, but I don't see a way for the tool to be
> able
> to tell that a set of attributes are part of a group from which one
> alternative
> must be chosen.
>
> Otherwise, the interface looks like it has everything that's needed, and
> would
> be straight-forward to use.
>
> Just to pick a nit here... do you think "alias" is the best name for the
> mechanism? To me, alias means "another name for the same thing", and that's
> not
> really what this mechanism is doing. It denotes a variation of an existing
> event (or attribute). In some cases, the variation may expand the what
> events
> are counted, and in other cases contract them, or in some cases measure
> different things. Maybe you could use "variant_of" (or just "variant")
> instead?
>
> Regards,
>
> - Corey
>
> Corey Ashford
> Software Engineer
> IBM Linux Technology Center, Linux Toolchain
> Beaverton, OR
> 503-578-3507
> [email protected]
>
>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
>
> ------------------------------
>
> _______________________________________________
> perfmon2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
>
>
> End of perfmon2-devel Digest, Vol 26, Issue 9
> *********************************************
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
perfmon2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
