From: "Robert Richter" <robert.richter@amd.com>
To: "David Rientjes" <rientjes@google.com>
Cc: "Stephane Eranian" <eranian@hpl.hp.com>,
"Andi Kleen" <andi@firstfloor.org>,
linux-kernel@vger.kernel.org
Subject: Re: [patch 2/8] 2.6.22-rc3 perfmon2 : Debug messages added
Date: Thu, 21 Jun 2007 16:00:24 +0200 [thread overview]
Message-ID: <20070621140024.GW24544@erda.amd.com> (raw)
In-Reply-To: <alpine.DEB.0.99.0706201245490.4562@chino.kir.corp.google.com>
On 20.06.07 12:49:05, David Rientjes wrote:
> On Wed, 20 Jun 2007, Robert Richter wrote:
>
> > Debug messages added for better debugging.
> >
>
> And you added BUG_ON()'s.
>
> > Signed-off-by: Robert Richter <robert.richter@amd.com>
> >
> > Index: linux-2.6.22-rc3/perfmon/perfmon_file.c
> > ===================================================================
> > --- linux-2.6.22-rc3.orig/perfmon/perfmon_file.c
> > +++ linux-2.6.22-rc3/perfmon/perfmon_file.c
> > @@ -192,6 +192,8 @@ static int pfm_mmap(struct file *file, s
> > unsigned long flags;
> > int ret;
> >
> > + PFM_DBG("pfm_file_ops");
>
> After commenting on your first set of patches, I've been using it a little
> more. In my use, these debugging messages weren't very helpful because
> "pfm_file_ops" can indicate pfm_mmap, pfm_read, pfm_poll, etc. Could
> these be changed to be more specific based on the function they're in?
>
> > Index: linux-2.6.22-rc3/perfmon/perfmon_syscalls.c
> > ===================================================================
> > --- linux-2.6.22-rc3.orig/perfmon/perfmon_syscalls.c
> > +++ linux-2.6.22-rc3/perfmon/perfmon_syscalls.c
> > @@ -403,6 +403,8 @@ asmlinkage long sys_pfm_create_context(s
> > void *fmt_arg = NULL;
> > int ret;
> >
> > + PFM_DBG("syscall");
>
> Likewise. Using "syscall" for all debugging messages in the syscall
> handlers isn't very informative. Could this be PFM_DBG(__FUNCTION__)
> instead?
>
> > +
> > if (atomic_read(&perfmon_disabled))
> > return -ENOSYS;
> >
> > @@ -433,8 +435,12 @@ asmlinkage long sys_pfm_write_pmcs(int f
> > size_t sz;
> > int ret, fput_needed;
> >
> > - if (count < 0 || count >= PFM_MAX_ARG_COUNT(ureq))
> > + PFM_DBG("syscall");
> > +
> > + if (count < 0 || count >= PFM_MAX_ARG_COUNT(ureq)) {
> > + PFM_DBG("invalid arg count %d", count);
>
> This is whitespace damaged.
Fixed in patch version 3.
>
> > return -EINVAL;
> > + }
> >
> > sz = count*sizeof(*ureq);
> >
> > @@ -475,6 +481,8 @@ asmlinkage long sys_pfm_write_pmcs(int f
> > kfree(fptr);
> > error:
> > fput_light(filp, fput_needed);
> > + if (ret)
> > + PFM_DBG("failed: errno=%d", -ret);
>
> What failed? More information would be helpful since this is, after all,
> a diagnostic message.
Removed in version 3.
>
> > Index: linux-2.6.22-rc3/include/asm-i386/perfmon.h
> > ===================================================================
> > --- linux-2.6.22-rc3.orig/include/asm-i386/perfmon.h
> > +++ linux-2.6.22-rc3/include/asm-i386/perfmon.h
> > @@ -140,6 +140,10 @@ static inline void pfm_arch_write_pmc(st
> > if (ctx && ctx->flags.started == 0)
> > return;
> >
> > + PFM_DBG_ovfl("pfm_arch_write_pmc(0x%016Lx, 0x%016Lx)",
> > + (unsigned long long) pfm_pmu_conf->pmc_desc[cnum].hw_addr,
> > + (unsigned long long) value);
>
> Casting here should be unnecessary. Changing %L would be advisible to
> display the data as it is stored in the object.
Not casting here would lead to warnings if compiling a 32 bit kernel.
>
> > + BUG_ON(pfm_pmu_conf->pmc_desc[cnum].type & PFM_REG_V);
> > if (arch_info->pmu_style == PFM_X86_PMU_P4)
> > __pfm_write_reg_p4(&arch_info->pmc_addrs[cnum], value);
> > else
> > @@ -155,6 +159,10 @@ static inline void pfm_arch_write_pmd(st
> > if (pfm_pmu_conf->pmd_desc[cnum].type & PFM_REG_C64)
> > value |= ~pfm_pmu_conf->ovfl_mask;
> >
> > + PFM_DBG_ovfl("pfm_arch_write_pmd(0x%016Lx, 0x%016Lx)",
> > + (unsigned long long) pfm_pmu_conf->pmd_desc[cnum].hw_addr,
> > + (unsigned long long) value);
> > + BUG_ON(pfm_pmu_conf->pmd_desc[cnum].type & PFM_REG_V);
> > if (arch_info->pmu_style == PFM_X86_PMU_P4)
> > __pfm_write_reg_p4(&arch_info->pmd_addrs[cnum], value);
> > else
> > @@ -165,10 +173,14 @@ static inline u64 pfm_arch_read_pmd(stru
> > {
> > struct pfm_arch_pmu_info *arch_info = pfm_pmu_conf->arch_info;
> > u64 tmp;
> > + BUG_ON(pfm_pmu_conf->pmd_desc[cnum].type & PFM_REG_V);
> > if (arch_info->pmu_style == PFM_X86_PMU_P4)
> > __pfm_read_reg_p4(&arch_info->pmd_addrs[cnum], &tmp);
> > else
> > rdmsrl(pfm_pmu_conf->pmd_desc[cnum].hw_addr, tmp);
> > + PFM_DBG_ovfl("pfm_arch_read_pmd(0x%016Lx) = 0x%016Lx",
> > + (unsigned long long) pfm_pmu_conf->pmd_desc[cnum].hw_addr,
> > + (unsigned long long) tmp);
> > return tmp;
> > }
> >
> > @@ -176,10 +188,14 @@ static inline u64 pfm_arch_read_pmc(stru
> > {
> > struct pfm_arch_pmu_info *arch_info = pfm_pmu_conf->arch_info;
> > u64 tmp;
> > + BUG_ON(pfm_pmu_conf->pmc_desc[cnum].type & PFM_REG_V);
> > if (arch_info->pmu_style == PFM_X86_PMU_P4)
> > __pfm_read_reg_p4(&arch_info->pmc_addrs[cnum], &tmp);
> > else
> > rdmsrl(pfm_pmu_conf->pmc_desc[cnum].hw_addr, tmp);
> > + PFM_DBG_ovfl("pfm_arch_read_pmc(0x%016Lx) = 0x%016Lx",
> > + (unsigned long long) pfm_pmu_conf->pmc_desc[cnum].hw_addr,
> > + (unsigned long long) tmp);
>
> More whitespace damage.
Fixed in patch version 3.
>
>
-Robert
--
AMD Saxony, Dresden, Germany
Operating System Research Center
email: robert.richter@amd.com
next prev parent reply other threads:[~2007-06-21 14:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070620182126.248753000@amd.com>
2007-06-20 18:41 ` [patch 1/8] 2.6.22-rc3 perfmon2 : Barcelona CPU detection Robert Richter
2007-06-20 19:45 ` David Rientjes
2007-06-21 10:29 ` Robert Richter
2007-06-20 18:41 ` [patch 2/8] 2.6.22-rc3 perfmon2 : Debug messages added Robert Richter
2007-06-20 19:49 ` David Rientjes
2007-06-20 20:22 ` Stephane Eranian
2007-06-20 20:28 ` David Rientjes
2007-06-20 20:39 ` Stephane Eranian
2007-06-20 20:45 ` David Rientjes
2007-06-20 20:54 ` Stephane Eranian
2007-06-21 10:30 ` Robert Richter
2007-06-21 14:00 ` Robert Richter [this message]
2007-06-21 12:32 ` Andi Kleen
2007-06-20 18:41 ` [patch 3/8] 2.6.22-rc3 perfmon2 : Minor changes Robert Richter
2007-06-20 18:41 ` [patch 4/8] 2.6.22-rc3 perfmon2 : Rearrangement of AMD64 MSR definitions, 2nd try Robert Richter
2007-06-20 18:41 ` [patch 5/8] 2.6.22-rc3 perfmon2 : Initial AMD64 PMU configuration Robert Richter
2007-06-20 18:41 ` [patch 6/8] 2.6.22-rc3 perfmon2 : IBS implementation for AMD64 Robert Richter
2007-06-20 20:43 ` Stephane Eranian
2007-06-20 18:41 ` [patch 7/8] 2.6.22-rc3 perfmon2 : Renaming *_k8_* symbols to *_amd64_* Robert Richter
2007-06-20 19:43 ` David Rientjes
2007-06-21 14:00 ` Robert Richter
2007-06-20 18:42 ` [patch 8/8] 2.6.22-rc3 perfmon2 : Renaming of module perfmon_k8 to perfmon_amd64 Robert Richter
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=20070621140024.GW24544@erda.amd.com \
--to=robert.richter@amd.com \
--cc=andi@firstfloor.org \
--cc=eranian@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
/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