Mailing List Archive: Linux: Kernel

[RFC PATCH -v2 0/4] Persistent events

Index | Next | Previous | View Threaded

bp at amd64

Aug 16, 2012, 10:45 AM

Post #1 of 14 (132 views)
Permalink

[RFC PATCH -v2 0/4] Persistent events

From: Borislav Petkov <borislav.petkov [at] amd>

Hi all,

off and on I get some free time to work on that, here's the latest
incarnation. It contains review feedback from the earlier round.

Patch 1/4 adds a trace_add_file() interface which adds an additional
file to debugfs, in this case the "persistent" file which contains the
normal perf file descriptor sys_perf_event_open gives to the perf tool.

IOW, one gets:

/mnt/dbg/tracing/events/mce/mce_record/
|-- enable
|-- filter
|-- format
|-- id
`-- persistent1

0 directories, 5 files

[. 1 is the CPU number so sticking all per-CPU descriptors in this
directory could get a little cluttered and ugly so I'll have to think
about that a bit more. ]

3/4 is the meat which adds <kernel/events/persistent.c> and 4/4 shows
how one can init a persistent event on a CPU.

What remains is adding code which can enable events on boot from the
kernel cmdline and more testing.

As always, comments and suggestions are appreciated.

Thanks.

Borislav Petkov (4):
trace events: Interface to add files to debugfs
perf: Add persistent events
perf: Add persistent event facilities
persistent test

arch/x86/include/asm/mce.h | 1 +
arch/x86/kernel/cpu/mcheck/mce.c | 5 ++
include/linux/ftrace_event.h | 3 +
include/linux/perf_event.h | 24 +++++-
kernel/events/Makefile | 2 +-
kernel/events/core.c | 18 +++--
kernel/events/internal.h | 2 +
kernel/events/persistent.c | 168 +++++++++++++++++++++++++++++++++++++++
kernel/trace/trace.c | 4 +
kernel/trace/trace.h | 1 +
kernel/trace/trace_events.c | 35 ++++++++
11 files changed, 254 insertions(+), 9 deletions(-)
create mode 100644 kernel/events/persistent.c

--
1.7.11.rc1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

corbet at lwn

Aug 16, 2012, 1:12 PM

Post #2 of 14 (127 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Thu, 16 Aug 2012 19:45:19 +0200
Borislav Petkov <bp [at] amd64> wrote:

> off and on I get some free time to work on that, here's the latest
> incarnation. It contains review feedback from the earlier round.

Can I add one small request for the next round? I've looked through the
patches and the code a bit, and I still have absolutely no clue of what a
"persistent event" is or why I might want one. Now, admittedly, I'm
slower than most, but it still might not hurt to add some overall
description of what this is for...?

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

bp at amd64

Aug 16, 2012, 1:55 PM

Post #3 of 14 (130 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

Hi Jon,

On Thu, Aug 16, 2012 at 02:12:53PM -0600, Jonathan Corbet wrote:
> On Thu, 16 Aug 2012 19:45:19 +0200
> Borislav Petkov <bp [at] amd64> wrote:
>
> > off and on I get some free time to work on that, here's the latest
> > incarnation. It contains review feedback from the earlier round.
>
> Can I add one small request for the next round? I've looked through the
> patches and the code a bit, and I still have absolutely no clue of what a
> "persistent event" is or why I might want one. Now, admittedly, I'm
> slower than most, but it still might not hurt to add some overall
> description of what this is for...?

yeah, maybe the naming is not the most fitting one but here's the basic
idea:

Normally, you enable perf events for a duration of time where you trace
your workload and then you disable them. In contrast, persistent events
are perf events which you enable at system boot and they remain enabled
- thus persistent - during the whole system lifetime.

The machinery logs all events and carries them out to userspace. Much
like the blackbox of a plane which records system events during the
whole flight.

And the usecase here is that we want the machine check code to log
machine checks during the whole system lifetime using the perf/trace
events infrastructure. And this happens regardless of whether there's a
userspace consumer of the logged data. Normally, we'll have one though
:).

MCA and the trace_mce_record() tracepoint is thus is the first user of
the persistent events but there might be others.

Please follow this thread:
http://marc.info/?l=linux-kernel&m=133234057614885 for some more
thoughts on the idea.

Of course, this whole thing is basically a rough draft and we're still
hammering out the details as we go.

Thanks.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rostedt at goodmis

Aug 16, 2012, 2:13 PM

Post #4 of 14 (129 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Thu, 2012-08-16 at 22:55 +0200, Borislav Petkov wrote:
> Hi Jon,
>
> On Thu, Aug 16, 2012 at 02:12:53PM -0600, Jonathan Corbet wrote:
> > On Thu, 16 Aug 2012 19:45:19 +0200
> > Borislav Petkov <bp [at] amd64> wrote:
> >
> > > off and on I get some free time to work on that, here's the latest
> > > incarnation. It contains review feedback from the earlier round.
> >
> > Can I add one small request for the next round? I've looked through the
> > patches and the code a bit, and I still have absolutely no clue of what a
> > "persistent event" is or why I might want one. Now, admittedly, I'm
> > slower than most, but it still might not hurt to add some overall
> > description of what this is for...?
>
> yeah, maybe the naming is not the most fitting one but here's the basic
> idea:
>
> Normally, you enable perf events for a duration of time where you trace
> your workload and then you disable them. In contrast, persistent events
> are perf events which you enable at system boot and they remain enabled
> - thus persistent - during the whole system lifetime.
>
> The machinery logs all events and carries them out to userspace. Much
> like the blackbox of a plane which records system events during the
> whole flight.
>
> And the usecase here is that we want the machine check code to log
> machine checks during the whole system lifetime using the perf/trace
> events infrastructure. And this happens regardless of whether there's a
> userspace consumer of the logged data. Normally, we'll have one though
> :).
>
> MCA and the trace_mce_record() tracepoint is thus is the first user of
> the persistent events but there might be others.
>
> Please follow this thread:
> http://marc.info/?l=linux-kernel&m=133234057614885 for some more
> thoughts on the idea.
>
> Of course, this whole thing is basically a rough draft and we're still
> hammering out the details as we go.

BTW, we already have a persistent buffering in the kernel. It's used by
ftrace. What about having perf use that buffering for persistent events?
Or is there some other issues about using it.

I'm currently working on having perf read ftrace data, so in the near
future, I plan on having some RFC patches to have perf reading from this
buffer anyway.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

bp at amd64

Aug 16, 2012, 2:41 PM

Post #5 of 14 (124 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Thu, Aug 16, 2012 at 05:13:33PM -0400, Steven Rostedt wrote:
> BTW, we already have a persistent buffering in the kernel. It's used
> by ftrace. What about having perf use that buffering for persistent
> events? Or is there some other issues about using it.

Not that I know of.

I coded this with the perf ring buffer now. If only there was one ring
buffer in the kernel.. /me ducks and hides.

Ok, with perf I can read out the events programmatically by mmaping the
per-CPU buffer with perf_mmap. How do you do that in ftrace? Any code
pointers I can stare at?

> I'm currently working on having perf read ftrace data, so in the near
> future, I plan on having some RFC patches to have perf reading from
> this buffer anyway.

Are you saying the ftrace buffer would be mmappable too now?

Btw, I wanted to hear your opinion on patch 1/4 since it touches
ftrace/trace_events code. Can you please look at it and tell me if its
ok?

Thanks.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rostedt at goodmis

Aug 16, 2012, 3:00 PM

Post #6 of 14 (125 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Thu, 2012-08-16 at 23:41 +0200, Borislav Petkov wrote:
> On Thu, Aug 16, 2012 at 05:13:33PM -0400, Steven Rostedt wrote:
> > BTW, we already have a persistent buffering in the kernel. It's used
> > by ftrace. What about having perf use that buffering for persistent
> > events? Or is there some other issues about using it.
>
> Not that I know of.
>
> I coded this with the perf ring buffer now. If only there was one ring
> buffer in the kernel.. /me ducks and hides.

:)

>
> Ok, with perf I can read out the events programmatically by mmaping the
> per-CPU buffer with perf_mmap. How do you do that in ftrace? Any code
> pointers I can stare at?

Do these need to be mmapped, or are they copied into another location
(disk or network)? I had code to allow the ftrace ring buffers to be
mmapped, but stopped that work a while ago.

>
> > I'm currently working on having perf read ftrace data, so in the near
> > future, I plan on having some RFC patches to have perf reading from
> > this buffer anyway.
>
> Are you saying the ftrace buffer would be mmappable too now?

No, the ftrace buffer was optimized for the splice command. I would have
perf do what trace-cmd does. That is, write directly into a file as it
reads it, without ever needing the info to come into userspace. I wasn't
planning on replacing perf buffers, I was just planning on giving perf a
tracing boost.

Another alternative, which would be a bit slower, would be to copy the
pages, either into userspace (as a read) or into a location to mmap the
buffers.

I could also continue the work on allowing ftrace buffers to be mmapped.
But if the best thing to do is just use the perf buffers, then we could
just stick with that.

>
> Btw, I wanted to hear your opinion on patch 1/4 since it touches
> ftrace/trace_events code. Can you please look at it and tell me if its
> ok?
>

I'll take a look.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

bp at amd64

Aug 17, 2012, 12:38 AM

Post #7 of 14 (120 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Thu, Aug 16, 2012 at 06:00:18PM -0400, Steven Rostedt wrote:
> Do these need to be mmapped, or are they copied into another location
> (disk or network)? I had code to allow the ftrace ring buffers to be
> mmapped, but stopped that work a while ago.

Well, my angle here is that since those are persistent, i.e. always-on
events, they should be as low overhead as possible. So mmaping the
buffer is probably that since it doesn't involve any data shuffling to
and fro...

> > > I'm currently working on having perf read ftrace data, so in the near
> > > future, I plan on having some RFC patches to have perf reading from
> > > this buffer anyway.
> >
> > Are you saying the ftrace buffer would be mmappable too now?
>
> No, the ftrace buffer was optimized for the splice command.

Ah, the splice thing moving data between two fds.

> I would have perf do what trace-cmd does. That is, write directly into
> a file as it reads it, without ever needing the info to come into
> userspace.

Is that a real file?

Because what I was doing in the RAS daemon is mmap the buffer, read out
the logged events in userspace and work on them.

Having them go to a file which I need to open in userspace adds one more
step and I don't know how that would pan out in a critical situation of
you getting a machine check where every insn counts. And besides, in a
MCE situation you cannot be sure that the events would actually go to
file... So my current impression is that reading them direct from memory
is the fastest we can do. But this is only me and I have been wrong in
the past. Lotsa times :).

> I wasn't planning on replacing perf buffers, I was just planning on
> giving perf a tracing boost.

Cool.

> Another alternative, which would be a bit slower, would be to copy the
> pages, either into userspace (as a read) or into a location to mmap the
> buffers.

Yeah, copying is not a good idea, IMHO, due to the said above.

> I could also continue the work on allowing ftrace buffers to be
> mmapped. But if the best thing to do is just use the perf buffers,
> then we could just stick with that.

The easiest for now, I'd say, since it is already there.

> > Btw, I wanted to hear your opinion on patch 1/4 since it touches
> > ftrace/trace_events code. Can you please look at it and tell me if its
> > ok?
> >
> I'll take a look.

Thanks.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rostedt at goodmis

Aug 17, 2012, 8:20 AM

Post #8 of 14 (122 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Fri, 2012-08-17 at 09:38 +0200, Borislav Petkov wrote:
> On Thu, Aug 16, 2012 at 06:00:18PM -0400, Steven Rostedt wrote:
> > Do these need to be mmapped, or are they copied into another location
> > (disk or network)? I had code to allow the ftrace ring buffers to be
> > mmapped, but stopped that work a while ago.
>
> Well, my angle here is that since those are persistent, i.e. always-on
> events, they should be as low overhead as possible. So mmaping the
> buffer is probably that since it doesn't involve any data shuffling to
> and fro...

Understood.

>
> > > > I'm currently working on having perf read ftrace data, so in the near
> > > > future, I plan on having some RFC patches to have perf reading from
> > > > this buffer anyway.
> > >
> > > Are you saying the ftrace buffer would be mmappable too now?
> >
> > No, the ftrace buffer was optimized for the splice command.
>
> Ah, the splice thing moving data between two fds.

Yep.

>
> > I would have perf do what trace-cmd does. That is, write directly into
> > a file as it reads it, without ever needing the info to come into
> > userspace.
>
> Is that a real file?

It's anything that needs a file descriptor. But yeah.

>
> Because what I was doing in the RAS daemon is mmap the buffer, read out
> the logged events in userspace and work on them.

OK, so you're not storing the data, your just using it to manipulate it.

If it wasn't for sparc, we could have done this with the ftrace buffers,
but sparc has some crazy requirement that physical pages can only be
mapped at certain locations, and you can't just take a bunch of random
pages and map them at the same location.

>
> Having them go to a file which I need to open in userspace adds one more
> step and I don't know how that would pan out in a critical situation of
> you getting a machine check where every insn counts. And besides, in a
> MCE situation you cannot be sure that the events would actually go to
> file... So my current impression is that reading them direct from memory
> is the fastest we can do. But this is only me and I have been wrong in
> the past. Lotsa times :).
>
> > I wasn't planning on replacing perf buffers, I was just planning on
> > giving perf a tracing boost.
>
> Cool.
>
> > Another alternative, which would be a bit slower, would be to copy the
> > pages, either into userspace (as a read) or into a location to mmap the
> > buffers.
>
> Yeah, copying is not a good idea, IMHO, due to the said above.

I agree.

>
> > I could also continue the work on allowing ftrace buffers to be
> > mmapped. But if the best thing to do is just use the perf buffers,
> > then we could just stick with that.
>
> The easiest for now, I'd say, since it is already there.

Yeah, I agree with this too. As the perf buffer is better for
manipulating of data and not storing it.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

peterz at infradead

Aug 17, 2012, 10:06 AM

Post #9 of 14 (119 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Fri, 2012-08-17 at 11:20 -0400, Steven Rostedt wrote:
> If it wasn't for sparc, we could have done this with the ftrace buffers,
> but sparc has some crazy requirement that physical pages can only be
> mapped at certain locations, and you can't just take a bunch of random
> pages and map them at the same location.

same problem for perf.. I've meant to make it either mmap or splice but
not both, but I've never gotten around to actually implement any of
that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

peterz at infradead

Aug 21, 2012, 3:30 AM

Post #10 of 14 (112 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Thu, 2012-08-16 at 19:45 +0200, Borislav Petkov wrote:
>
> off and on I get some free time to work on that, here's the latest
> incarnation. It contains review feedback from the earlier round.
>
> Patch 1/4 adds a trace_add_file() interface which adds an additional
> file to debugfs, in this case the "persistent" file which contains the
> normal perf file descriptor sys_perf_event_open gives to the perf tool.
>
> IOW, one gets:
>
> /mnt/dbg/tracing/events/mce/mce_record/
> |-- enable
> |-- filter
> |-- format
> |-- id
> `-- persistent1
>
> 0 directories, 5 files
>
> [. 1 is the CPU number so sticking all per-CPU descriptors in this
> directory could get a little cluttered and ugly so I'll have to think
> about that a bit more. ]
>
> 3/4 is the meat which adds <kernel/events/persistent.c> and 4/4 shows
> how one can init a persistent event on a CPU.
>
> What remains is adding code which can enable events on boot from the
> kernel cmdline and more testing.
>
> As always, comments and suggestions are appreciated.

Good progress there, there's still a few things though:

- the point also raised by Steven, I'm pretty sure that the placing of
the debugfs files unfortunate. I would much rather see something
like /debug/perf/persistent/$foo, also dropping your
perf_event_desc::dir_name.

- I would make perf_add_persistent_on_cpu() static and create something
like perf_add_persistent() which iterates all CPUs and creates:
"%s-%04d", perf_event_desc::fname, cpu. This needs a little extra for
cpu-hotplug, not sure what to do there.

- related to the first point, by not tying them to actual events you
can create a persistent 'event' that contains multiple events. Its
quite possible to create multiple kernel events and use the
equivalent of PERF_EVENT_IOC_SET_OUTPUT on them to the exposed FD.

- It might be good to provide means of changing the persistent event's
buffer size, or maybe even 'destroy' persistent buffers.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

bp at amd64

Aug 21, 2012, 6:11 AM

Post #11 of 14 (113 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Tue, Aug 21, 2012 at 12:30:50PM +0200, Peter Zijlstra wrote:
> Good progress there, there's still a few things though:
>
> - the point also raised by Steven, I'm pretty sure that the placing of
> the debugfs files unfortunate. I would much rather see something
> like /debug/perf/persistent/$foo, also dropping your
> perf_event_desc::dir_name.

Ok, how do we want to do the per-CPU layout there? Like this:

/debug/perf/persistent/mce_record0
/debug/perf/persistent/mce_record1
...

or rather

/debug/perf/persistent/cpu0/mce_record
/debug/perf/persistent/cpu1/mce_record

?

The thing is, I'm not sure we want to make persistent events per-CPU
implicitly. If yes, then the second layout would fit better. Hmm.

> - I would make perf_add_persistent_on_cpu() static and create
> something like perf_add_persistent() which iterates all CPUs and
> creates: "%s-%04d", perf_event_desc::fname, cpu.

Ok.

> This needs a little extra for cpu-hotplug, not sure what to do there.

get/put_online_cpus()?

and then maybe check whether some of the CPUs are offline and warn if
so?

> - related to the first point, by not tying them to actual events
> you can create a persistent 'event' that contains multiple events.
> Its quite possible to create multiple kernel events and use the
> equivalent of PERF_EVENT_IOC_SET_OUTPUT on them to the exposed FD.

Hm, interesting.

So, in that case, the persistent thing would have a per-CPU buffer and
a file descriptor connected to it and one would be able to add events
which would log into the per-CPU buffer. Ok.

> - It might be good to provide means of changing the persistent
> event's buffer size, or maybe even 'destroy' persistent buffers.

ioctl? Or something else?

Thanks.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rostedt at goodmis

Aug 21, 2012, 6:41 AM

Post #12 of 14 (110 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Tue, 2012-08-21 at 15:11 +0200, Borislav Petkov wrote:
> On Tue, Aug 21, 2012 at 12:30:50PM +0200, Peter Zijlstra wrote:
> > Good progress there, there's still a few things though:
> >
> > - the point also raised by Steven, I'm pretty sure that the placing of
> > the debugfs files unfortunate. I would much rather see something
> > like /debug/perf/persistent/$foo, also dropping your
> > perf_event_desc::dir_name.
>
> Ok, how do we want to do the per-CPU layout there? Like this:
>
> /debug/perf/persistent/mce_record0
> /debug/perf/persistent/mce_record1
> ...
>
> or rather
>
> /debug/perf/persistent/cpu0/mce_record
> /debug/perf/persistent/cpu1/mce_record
>
> ?

Definitely the second one. The first one is just ugly. The second is
more in line to the tracing directories too:

/debug/tracing/per_cpu/cpu0/...

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

bp at amd64

Aug 21, 2012, 6:50 AM

Post #13 of 14 (110 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Tue, Aug 21, 2012 at 09:41:15AM -0400, Steven Rostedt wrote:
> Definitely the second one. The first one is just ugly. The second is
> more in line to the tracing directories too:
>
> /debug/tracing/per_cpu/cpu0/...

Maybe I can reuse your code and add

/debug/tracing/per_cpu/cpu0/persistent/<event>

?

It is basically debugfs handling, right? Or are you reworking that
too?

Thanks.

--
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rostedt at goodmis

Aug 21, 2012, 7:03 AM

Post #14 of 14 (110 views)
Permalink

Re: [RFC PATCH -v2 0/4] Persistent events [In reply to]

On Tue, 2012-08-21 at 15:50 +0200, Borislav Petkov wrote:
> On Tue, Aug 21, 2012 at 09:41:15AM -0400, Steven Rostedt wrote:
> > Definitely the second one. The first one is just ugly. The second is
> > more in line to the tracing directories too:
> >
> > /debug/tracing/per_cpu/cpu0/...
>
> Maybe I can reuse your code and add
>
> /debug/tracing/per_cpu/cpu0/persistent/<event>
>
> ?
>
> It is basically debugfs handling, right? Or are you reworking that
> too?
>

Anything global wont be modified. IOW, tools wont break :-)

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads