lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG2=9p96Bu3Q53MS1era_a6L6Ruuba2H2khDHrP-UZD6hL2McQ@mail.gmail.com>
Date:	Fri, 17 Jul 2015 13:59:10 +0800
From:	Chunyan Zhang <zhang.chunyan@...aro.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Serge Broslavsky <serge.broslavsky@...aro.org>,
	broonie@...nel.org,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Lyra Zhang <zhang.lyra@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks

On Wed, Jul 8, 2015 at 9:19 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Wed, 8 Jul 2015 14:31:48 +0200
> Peter Zijlstra <peterz@...radead.org> wrote:
>
>> On Tue, Jul 07, 2015 at 06:10:43PM +0800, Chunyan Zhang wrote:
>> > Add the function 'trace_event_stm_output_##call' for printing events
>> > trace log into STM blocks.
>> >
>> > This patch also adds a function call at where the events have been
>> > committed to ring buffer to export the trace event information to
>> > STM blocks.
>>
>> So then you have two copies of the data, why that? Would a scheme were
>> data either goes to the STM or the regular buffer not make much more
>> sense?
>>
>> > +++ b/include/trace/perf.h
>> > @@ -175,6 +175,7 @@ trace_event_raw_event_##call(void *__data, proto)                       \
>> >     { assign; }                                                     \
>> >                                                                     \
>> >     trace_event_buffer_commit(&fbuffer);                            \
>> > +   trace_event_stm_log(&fbuffer);                                  \
>>
>> This makes every trace event slower.
>
> Of course this could use a jump label.
>
> But I agree, I think a switch to which buffer it should be sent to is
> better. I could come up with a way to make the buffer more generic, and
> have it switch between where the event is recorded.
>

Hello Steve,

Please excuse my disturbing you again.

May I get more details of how you want the code (including Trace Event
and STM subsystem) will be reworked?
I know you are very busy, maybe I can more or less help with
something. I'm eager to do that, but the problem for now is I think
I'm not in the same level for the understanding of next work we need
to do.
Do you have an exact solution already? or some ideas you want me to try?


Looking forward to your reply, thank you!
Chunyan


> -- Steve
>
>>
>> >  }
>> >  /*
>> >   * The ftrace_test_probe is compiled out, it is only here as a build time check
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ