Prev: [tip:x86/mrst] x86, mrst: make mrst_identify_cpu() an inline returning enum
Next: drivers/media/video/uvc: Use kmemdup
From: Robert Richter on 20 May 2010 11:50
On 20.05.10 10:14:46, Stephane Eranian wrote:

> > We have some bits in the msrs that are reserved now, for perfctr and
> > also for ibs. We could start reusing it to mark a special sample type
> > and so on. So far, ok. Somewhen in the future there is a hw extensions
> > and these bits are not reserved anymore, what now?
> >
> You will always have the sampling period bits. Those will always be
> handled by attr->sample_period. And they correspond to the lower
> bits which are also used to encode the event select on regular counters.
> So you could identify IBS with special event selects in the lower 8 bits
> for instance.
>
> IBS is a very model specific feature, as such the method you use to
> encode it may change.

> In my new proposal, I am not using reserved bits, I am using bits which
> are stored elsewhere in the attr structure.

Ok, maybe technically it is possible for ibs and perfctrs. You are
moving the sample count from the raw config out to sample_count
attribute, then the type is written to the new free space in the raw
config. In the kernel you do all of this in reverse order. This makes
programming events really difficult and confusing. I don't see an
advantage compared to the use of a raw_type.

> There is no guarantee your scheme will help there either. Nobody knows
> the interface to those new features. It may be that you will need more than
> 64 bits.

Right, for more than 64 bit the need another extension.

> What I am missing with raw_type is how it plays out with attr->type which
> already has RAW? Seems like you have a second level of raw.

"raw_type" is only valid together with (attr->type == PERF_TYPE_RAW).
Currently it is null (bp_type is unused and zeroed). So (raw_type ==
0) will leave everything as it is and uses the archtectures default
raw config. If we set raw_type to a value other than zero, we have a
special configuration for a special pmu feature. It looks sane to me.

> Well, I don't think you want to define an attribute for each and every
> bit of info returned by IBS. I think you need to return the IBSDATA regs
> as is and let the user pick and choose. Of course, the information can
> change, but IBS is model specific, it returns something richer than just
> a count.

I think, we all agree the ibs sample should be send back to userland
also as raw sample.

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter(a)amd.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 20 May 2010 13:00

* Robert Richter <robert.richter(a)amd.com> wrote:

> On 20.05.10 06:37:39, Peter Zijlstra wrote:
>
> > So yeah, you might as well expose it as a whole separate PMU using Lin's
> > stuff.
>
> This seems to be the most promising alternative to raw_type. But it's also
> much more bloated requiring sysfs and additional file descriptors.

Not really, fds are really cheap on Linux, and in any case it's only needed
when the event is created - can be closed afterwards.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Richter on 20 May 2010 13:10
On 20.05.10 12:55:01, Ingo Molnar wrote:
> Not really, fds are really cheap on Linux, and in any case it's only needed
> when the event is created - can be closed afterwards.

I was wondering if we could get the perf event fd directly with the
open("/sys/...") command? This would be really easy to set up.

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter(a)amd.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 20 May 2010 13:20
On Thu, 2010-05-20 at 19:07 +0200, Robert Richter wrote:
> On 20.05.10 12:55:01, Ingo Molnar wrote:
> > Not really, fds are really cheap on Linux, and in any case it's only needed
> > when the event is created - can be closed afterwards.
>
> I was wondering if we could get the perf event fd directly with the
> open("/sys/...") command? This would be really easy to set up.

I guess we could sorta do that, but then we'd need a ioctl to change the
perf_event_attr.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Robert Richter on 20 May 2010 18:50
On 19.05.10 18:02:40, Corey Ashford wrote:

> > perf record -e r186A:IBS_FETCH ...
> > perf record -e r0:IBS_FETCH -c 100000 ...
>
> Should this raw value have been 186A0 instead of 186A?

This is the 20 bit value of the cycle count, but only bits 19:4 are
encoded in bits 15:0 of the raw ibs register. Lower 4 bits of the
cycle count must be null and thus not pushed to the register. The raw
register setup is correct.

> Where is the named type translation coming from? Is this something
> that needs to be hard-coded into perf?

I was thinking of an enum or macro definition for the values in the
kernel. A name mapping table could be implemented at least in the
userspace, if needed maybe also in the kernel.

> Have you looked at Lin Ming's patch series? I think it offers
> another way to support IBS and other arch-specific and off-chip PMUs
> in a more general way, though it's not quite fully-baked yet.

Yes, this could be an option too. The proposal was some days ago and a
little hidden in its subject, so I missed it first. But the concept of
registering a pmu feature looks good and could be an alternative to
the raw_value approach.

-Robert

--
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter(a)amd.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: [tip:x86/mrst] x86, mrst: make mrst_identify_cpu() an inline returning enum
Next: drivers/media/video/uvc: Use kmemdup