Prev: [PATCH -tip v2 2/5] [CLEANUP] kprobes: Remove redundant text_mutex lock in optimize
Next: perf: core, lookup pmu via sysfs
From: Greg KH on 19 May 2010 01:10
On Wed, May 19, 2010 at 11:40:29AM +0800, Lin Ming wrote:
> On Wed, 2010-05-19 at 10:48 +0800, Greg KH wrote:
> > On Wed, May 19, 2010 at 10:34:55AM +0800, Lin Ming wrote:
> > > /sys/devices/system/cpu/events/
> > > |-- L1-dcache-load-misses
> > > | |-- event_source -> ../../event_source
> > >
> > > For above example, "event_source" is the cpu pmu and the "event" is
> > > L1-dcache-load-misses.
> > >
> > > Yes, they point to the same thing, because all the events
> > > under /sys/devices/system/cpu/events/* is monitored by the same event
> > > source, ie, the cpu pmu(/sys/devices/system/cpu/event_source/).
> >
> > Then, why have a symlink if they are all going to be the same?
>
> So how about move the symlink to parent directory, like
>
> /sys/devices/system/cpu/event_source/
>
> /sys/devices/system/cpu/events/
> |-- event_source -> ../event_source

Again, why would that make any sense? You would be creating a symlink
to something that is always the same symlink. Why would that even be
needed?

> > > > I'm still not really understanding what exactly you are trying to show
> > > > in the sysfs tree here anyway, perhaps the documentation update will
> > > > clear that up for me.
> > >
> > > To support multiple pmus
> >
> > What is a "pmu"?
>
> Performance Monitoring Unit

What is a "unit"?

> > > (or call them event source),
> >
> > What is an "event source"?
>
> The source who generates the event.

The traditional way to define a word, or phrase, is to not use the word
or phrase in the definition, otherwise that definition makes no sense.

> The event includes hardware events, cache-misses, bus-cycles,
> interrupts, error conditions, hotplug......
> and software events, context-switches, page-faults, sched events......

So, stuff that happens to a CPU that are usually handled in the
performance counters portion of the CPU, right?

Why put this in sysfs? Why do you think that mapping this information
there makes sense?

> > > I want to show all
> > > the pmus and events in the sysfs tree.
> >
> > Why do these things need to be in sysfs? What benifit is it going to
> > have?
>
> Kernel to provide the information of the event source and
> hardware/software events via sysfs and user-space can get
> this info from sysfs.

But that's not what you were doing with your "open a sysfs file from
within the kernel and use the kobject there" logic, right? You were
doing everything within the kernel itself, so sysfs, and kobjects and
the like, aren't really needed at all, right?

How are you exporting this information to userspace today?

> > > For mce,
> > > /sys/kernel/events/mce/*
> >
> > What? No, don't create /sys/kernel/events/. Is that in this patchset?
>
> No, not in this patchset.

Good :)

> > Ick, that's such a "general" name that it is going to get confusing very
> > quickly. Heck, I still don't know what this "event" thing is yet :)
> >
> > > and so on...the exact placement is not yet final.
> >
> > Again, why do you need/want anything in sysfs in the first place?
> > What problem is it going to solve? Who is going to benifit? Why do
> > they care? What is this whole thing about?

You forgot to answer these questions...

thanks,

greg k-h
--
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: Lin Ming on 19 May 2010 02:40
On Wed, 2010-05-19 at 13:00 +0800, Greg KH wrote:
> On Wed, May 19, 2010 at 11:40:29AM +0800, Lin Ming wrote:
> > On Wed, 2010-05-19 at 10:48 +0800, Greg KH wrote:
> > > On Wed, May 19, 2010 at 10:34:55AM +0800, Lin Ming wrote:
> > > > /sys/devices/system/cpu/events/
> > > > |-- L1-dcache-load-misses
> > > > | |-- event_source -> ../../event_source
> > > >
> > > > For above example, "event_source" is the cpu pmu and the "event" is
> > > > L1-dcache-load-misses.
> > > >
> > > > Yes, they point to the same thing, because all the events
> > > > under /sys/devices/system/cpu/events/* is monitored by the same event
> > > > source, ie, the cpu pmu(/sys/devices/system/cpu/event_source/).
> > >
> > > Then, why have a symlink if they are all going to be the same?
> >
> > So how about move the symlink to parent directory, like
> >
> > /sys/devices/system/cpu/event_source/
> >
> > /sys/devices/system/cpu/events/
> > |-- event_source -> ../event_source
>
> Again, why would that make any sense? You would be creating a symlink
> to something that is always the same symlink. Why would that even be
> needed?

Do you mean the target of the symlink is also a symlink? No.

/sys/devices/system/cpu/events/event_source points
to /sys/devices/system/cpu/event_source.

/sys/devices/system/cpu/event_source/ is a sysfs dir, not a symlink.

>
> > > > > I'm still not really understanding what exactly you are trying to show
> > > > > in the sysfs tree here anyway, perhaps the documentation update will
> > > > > clear that up for me.
> > > >
> > > > To support multiple pmus
> > >
> > > What is a "pmu"?
> >
> > Performance Monitoring Unit
>
> What is a "unit"?
>
> > > > (or call them event source),
> > >
> > > What is an "event source"?
> >
> > The source who generates the event.
>
> The traditional way to define a word, or phrase, is to not use the word
> or phrase in the definition, otherwise that definition makes no sense.

Ingo's explanation looks much more clear.

<---snip start--->
We _really_ dont want to call it a 'PMU' but 'events coming from an event
source'.

The reason is that a PMU is an existing term that is quite attached to a CPU -
while many hardware events come not from a PMU. Interrupts, error conditions,
hotplug events, etc. etc.

Furthermore, the name 'PMU' is even less correct for software events.

So lets stick with 'events' and with some container that originates them.
(event_source) Ok?
<---snip end--->

>
> > The event includes hardware events, cache-misses, bus-cycles,
> > interrupts, error conditions, hotplug......
> > and software events, context-switches, page-faults, sched events......
>
> So, stuff that happens to a CPU that are usually handled in the
> performance counters portion of the CPU, right?

For cpu hardware events(cycles, branch-misses, L1-dcache-loads etc...),
yes.

>
> Why put this in sysfs? Why do you think that mapping this information
> there makes sense?

sysfs, "It provides a means to export kernel data structures, their
attributes, and the linkages between them to userspace."

pmus and events have attributes that userspace tool want to know, for
example, pmu id, event config value.

And they also have linkage, for example, cycles event uses cpu pmu to
handle it, so

/sys/devices/system/cpu/events/cycles/event_source
---> /sys/devices/system/cpu/event_source

>
> > > > I want to show all
> > > > the pmus and events in the sysfs tree.
> > >
> > > Why do these things need to be in sysfs? What benifit is it going to
> > > have?
> >
> > Kernel to provide the information of the event source and
> > hardware/software events via sysfs and user-space can get
> > this info from sysfs.
>
> But that's not what you were doing with your "open a sysfs file from
> within the kernel and use the kobject there" logic, right? You were
> doing everything within the kernel itself, so sysfs, and kobjects and
> the like, aren't really needed at all, right?

No.

In userspace, open a sysfs file, see patch 11.
Then pass the open file's fd to the syscall sys_perf_event_open.

In kernel, use the passed in fd to find the pmu.

>
> How are you exporting this information to userspace today?

Not export it today.

>
> > > > For mce,
> > > > /sys/kernel/events/mce/*
> > >
> > > What? No, don't create /sys/kernel/events/. Is that in this patchset?
> >
> > No, not in this patchset.
>
> Good :)
>
> > > Ick, that's such a "general" name that it is going to get confusing very
> > > quickly. Heck, I still don't know what this "event" thing is yet :)
> > >
> > > > and so on...the exact placement is not yet final.
> > >
> > > Again, why do you need/want anything in sysfs in the first place?
> > > What problem is it going to solve? Who is going to benifit? Why do
> > > they care? What is this whole thing about?
>
> You forgot to answer these questions...

Want to solve the problem of how to address an "event source".
I thought it's clear to export via sysfs, but, I maybe totally wrong...

Thanks,
Lin Ming

>
> thanks,
>
> greg k-h

--
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: Borislav Petkov on 19 May 2010 03:10
From: Lin Ming <ming.m.lin(a)intel.com>
Date: Wed, May 19, 2010 at 10:34:55AM +0800

Hi,

[..]

>
> For mce,
> /sys/kernel/events/mce/*

have we considered the per-cpu granularity of MCEs here and if yes, how
to represent that?

Something like

/sys/kernel/events/mce/cpus/cpuX/..

or similar maybe. One use case I can think of right now is being able to
inject an MCE on a certain cpu...

Thanks.

--
Regards/Gruss,
Boris.

Operating Systems Research Center
Advanced Micro Devices, Inc.
--
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 19 May 2010 03:20
On Wed, 2010-05-19 at 09:06 +0200, Borislav Petkov wrote:
>
> have we considered the per-cpu granularity of MCEs here and if yes, how
> to represent that?

Uhm, by opening the MCE event on a particular cpu? Remember that
sys_perf_event_open() has a cpu target.

The thing is, CPUs are assumed symmetric, thus also all MCE events are
symmetric, one CPU cannot generate other MCE than another. So the only
thing that differs is where you want to listen for them.
--
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 19 May 2010 03:30

* Peter Zijlstra <peterz(a)infradead.org> wrote:

> On Wed, 2010-05-19 at 09:06 +0200, Borislav Petkov wrote:
> >
> > have we considered the per-cpu granularity of MCEs
> > here and if yes, how to represent that?
>
> Uhm, by opening the MCE event on a particular cpu?
> Remember that sys_perf_event_open() has a cpu target.
>
> The thing is, CPUs are assumed symmetric, thus also all
> MCE events are symmetric, one CPU cannot generate other
> MCE than another. So the only thing that differs is
> where you want to listen for them.

Note, this does not preclude Linux from supporting
assymetric MP, should the need arise: if MP assymetry is
supported then that can (and should) be expressed in the
sysfs topology accordingly - and the moment the assymetric
MP topology is enumerated in sysfs it gives a place for
the different event_source's to live there as well.

Thanks,

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/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: [PATCH -tip v2 2/5] [CLEANUP] kprobes: Remove redundant text_mutex lock in optimize
Next: perf: core, lookup pmu via sysfs