On Wed, Dec 05, 2018 at 04:08:09PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> > On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > > On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> > > > On Tue, Dec 04, 2018
On Wed, Dec 05, 2018 at 04:08:09PM -0800, Paul E. McKenney wrote:
> On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> > On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > > On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> > > > On Tue, Dec 04, 2018
On Wed, Dec 5, 2018 at 2:00 PM Al Viro wrote:
>
> On Wed, Dec 05, 2018 at 01:16:01PM -0800, Todd Kjos wrote:
> > 44d8047f1d87a ("binder: use standard functions to allocate fds")
> > exposed a pre-existing issue in the binder driver.
> >
> > fdget() is used in ksys_ioctl() as a performance
On Wed, Dec 5, 2018 at 2:00 PM Al Viro wrote:
>
> On Wed, Dec 05, 2018 at 01:16:01PM -0800, Todd Kjos wrote:
> > 44d8047f1d87a ("binder: use standard functions to allocate fds")
> > exposed a pre-existing issue in the binder driver.
> >
> > fdget() is used in ksys_ioctl() as a performance
On Wed, 5 Dec 2018, Andrea Arcangeli wrote:
> __GFP_COMPACT_ONLY gave an hope it could give some middle ground but
> it shows awful compaction results, it basically destroys compaction
> effectiveness and we know why (COMPACT_SKIPPED must call reclaim or
> compaction can't succeed because there's
On Wed, 5 Dec 2018, Andrea Arcangeli wrote:
> __GFP_COMPACT_ONLY gave an hope it could give some middle ground but
> it shows awful compaction results, it basically destroys compaction
> effectiveness and we know why (COMPACT_SKIPPED must call reclaim or
> compaction can't succeed because there's
Hi,
On Wed, Nov 14, 2018 at 05:07:03PM +0800, Baolin Wang wrote:
> This patch set adds some new features for SC27XX fuel gauge driver.
>
> 1. Read calibration data from eFuse device to calibrate fuel gauge.
> 2. Add low voltage alarm to adjust the battery capacity in lower
> voltage stage.
> 3.
Hi,
On Wed, Nov 14, 2018 at 05:07:03PM +0800, Baolin Wang wrote:
> This patch set adds some new features for SC27XX fuel gauge driver.
>
> 1. Read calibration data from eFuse device to calibrate fuel gauge.
> 2. Add low voltage alarm to adjust the battery capacity in lower
> voltage stage.
> 3.
On Wed, Dec 5, 2018 at 3:27 PM Jerome Glisse wrote:
>
> On Wed, Dec 05, 2018 at 04:23:42PM -0700, Logan Gunthorpe wrote:
> >
> >
> > On 2018-12-05 4:20 p.m., Jerome Glisse wrote:
> > > And my proposal is under /sys/bus and have symlink to all existing
> > > device it agregate in there.
> >
> >
On Wed, Dec 5, 2018 at 3:27 PM Jerome Glisse wrote:
>
> On Wed, Dec 05, 2018 at 04:23:42PM -0700, Logan Gunthorpe wrote:
> >
> >
> > On 2018-12-05 4:20 p.m., Jerome Glisse wrote:
> > > And my proposal is under /sys/bus and have symlink to all existing
> > > device it agregate in there.
> >
> >
On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> > > On Tue, Dec 04, 2018 at 02:09:42PM -0800, tip-bot for Paul E. McKenney
> > > wrote:
> > > >
On Wed, Dec 05, 2018 at 02:25:24PM -0800, Josh Triplett wrote:
> On Tue, Dec 04, 2018 at 03:04:23PM -0800, Paul E. McKenney wrote:
> > On Tue, Dec 04, 2018 at 02:24:13PM -0800, Josh Triplett wrote:
> > > On Tue, Dec 04, 2018 at 02:09:42PM -0800, tip-bot for Paul E. McKenney
> > > wrote:
> > > >
> On Dec 4, 2018, at 5:34 PM, Nadav Amit wrote:
>
> A following patch is going to make module allocated memory
> non-executable. This requires to modify ftrace and make the memory
> executable again after it is configured.
>
> In addition, this patch makes ftrace use the general text poking
>
> On Dec 4, 2018, at 5:34 PM, Nadav Amit wrote:
>
> A following patch is going to make module allocated memory
> non-executable. This requires to modify ftrace and make the memory
> executable again after it is configured.
>
> In addition, this patch makes ftrace use the general text poking
>
The latest ARM CoreSight specification updates the component identification
requirements for all components attached to an AMBA bus. (ARM IHI 0029E)
This specification defines bits 15:12 in the ComponentID (CID) value as the
device class. Identification requirements now depend on this class.
The latest ARM CoreSight specification updates the component identification
requirements for all components attached to an AMBA bus. (ARM IHI 0029E)
This specification defines bits 15:12 in the ComponentID (CID) value as the
device class. Identification requirements now depend on this class.
Updates the ID register tables to contain a UCI entry for the A35 ETM
device to allow correct matching of driver in the amba bus code.
Signed-off-by: Mike Leach
---
drivers/hwtracing/coresight/coresight-etm4x.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git
The CoreSight specification (ARM IHI 0029E), updates the ID register
requirements for components on an AMBA bus, to cover both traditional
ARM Primecell type devices, and newer CoreSight and other components.
The Peripheral ID (PID) / Component ID (CID) pair is extended in certain
cases to
Updates the ID register tables to contain a UCI entry for the A35 ETM
device to allow correct matching of driver in the amba bus code.
Signed-off-by: Mike Leach
---
drivers/hwtracing/coresight/coresight-etm4x.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git
The CoreSight specification (ARM IHI 0029E), updates the ID register
requirements for components on an AMBA bus, to cover both traditional
ARM Primecell type devices, and newer CoreSight and other components.
The Peripheral ID (PID) / Component ID (CID) pair is extended in certain
cases to
Hello,
On Wed, Dec 05, 2018 at 01:59:32PM -0800, David Rientjes wrote:
> [..] and the kernel test robot has reported, [..]
Just for completeness you may have missed one email:
https://lkml.kernel.org/r/87tvk1yjkp@yhuang-dev.intel.com
'So I think the report should have been a "performance
Hello,
On Wed, Dec 05, 2018 at 01:59:32PM -0800, David Rientjes wrote:
> [..] and the kernel test robot has reported, [..]
Just for completeness you may have missed one email:
https://lkml.kernel.org/r/87tvk1yjkp@yhuang-dev.intel.com
'So I think the report should have been a "performance
Quoting Bjorn Andersson (2018-12-03 10:33:30)
> Add clkref clocks for usb3, hdmi, ufs, pcie, and usb2. They are all
> sourced off CXO_IN, so parent them off "xo" until a proper link to the
> rpmcc can be described in DT.
>
> Signed-off-by: Bjorn Andersson
> ---
Applied to clk-next
Quoting Bjorn Andersson (2018-12-03 10:33:29)
> Drop the halt check of the UFS symbol clocks, in accordance with other
> platforms. This makes clk_disable_unused() happy and makes it possible
> to turn the clocks on again without an error.
>
> Signed-off-by: Bjorn Andersson
> ---
Applied to
Quoting Bjorn Andersson (2018-12-03 10:33:30)
> Add clkref clocks for usb3, hdmi, ufs, pcie, and usb2. They are all
> sourced off CXO_IN, so parent them off "xo" until a proper link to the
> rpmcc can be described in DT.
>
> Signed-off-by: Bjorn Andersson
> ---
Applied to clk-next
Quoting Bjorn Andersson (2018-12-03 10:33:29)
> Drop the halt check of the UFS symbol clocks, in accordance with other
> platforms. This makes clk_disable_unused() happy and makes it possible
> to turn the clocks on again without an error.
>
> Signed-off-by: Bjorn Andersson
> ---
Applied to
Quoting Bjorn Andersson (2018-12-03 10:33:28)
> Disabling gcc_hmss_dvm_bus_clk and gcc_lpass_at_clk causes the board to
> lock up, and by that preventing the kernel to boot without
> clk_ignore_unused.
>
> gcc_hmss_dvm_bus_clk is marked always-on downstream, but not referenced,
> and
Quoting Bjorn Andersson (2018-12-03 10:33:28)
> Disabling gcc_hmss_dvm_bus_clk and gcc_lpass_at_clk causes the board to
> lock up, and by that preventing the kernel to boot without
> clk_ignore_unused.
>
> gcc_hmss_dvm_bus_clk is marked always-on downstream, but not referenced,
> and
This patch adds an option to compile-in a high resolution
and large Terminus (ter16x32) bitmap console font for use with
HiDPI and Retina screens.
The font was convereted from standard Terminus ter-i32b.psf
(size 16x32) with the help of psftools and minor hand editing
deleting useless characters.
This patch adds an option to compile-in a high resolution
and large Terminus (ter16x32) bitmap console font for use with
HiDPI and Retina screens.
The font was convereted from standard Terminus ter-i32b.psf
(size 16x32) with the help of psftools and minor hand editing
deleting useless characters.
Quoting Jeffrey Hugo (2018-12-04 07:13:22)
> The current list of defined resets is incomplete compared to what the
> hardware implements. Enumerate the remaining resets according to the
> hardware documentation.
>
> Signed-off-by: Jeffrey Hugo
> ---
Applied to clk-next
Quoting Jeffrey Hugo (2018-12-04 07:13:22)
> The current list of defined resets is incomplete compared to what the
> hardware implements. Enumerate the remaining resets according to the
> hardware documentation.
>
> Signed-off-by: Jeffrey Hugo
> ---
Applied to clk-next
On 12/4/18 3:49 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.143 release.
There are 50 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 12/4/18 3:49 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.143 release.
There are 50 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
On 12/4/18 3:48 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.86 release.
There are 146 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
On 12/4/18 3:48 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.86 release.
There are 146 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be
GT5663 is capacitive touch controller with customized smart
wakeup gestures, it support chipdata which is similar to
existing GT1151 and require AVDD28 supply for some boards.
Document the compatible for the same.
Signed-off-by: Jagan Teki
---
Changes for v2:
- drop example node
GT5663 is capacitive touch controller with customized smart
wakeup gestures, it support chipdata which is similar to
existing GT1151 and require AVDD28 supply for some boards.
Document the compatible for the same.
Signed-off-by: Jagan Teki
---
Changes for v2:
- drop example node
On 12/4/18 3:48 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.7 release.
There are 139 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Most of the Goodix CTP controllers are supply with AVDD28 pin.
which need to supply for controllers like GT5663 on some boards
to trigger the power.
So, document the supply property so-that the required board
that used on GT5663 can enable it via device tree.
Signed-off-by: Jagan Teki
---
On 12/4/18 3:48 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.7 release.
There are 139 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Most of the Goodix CTP controllers are supply with AVDD28 pin.
which need to supply for controllers like GT5663 on some boards
to trigger the power.
So, document the supply property so-that the required board
that used on GT5663 can enable it via device tree.
Signed-off-by: Jagan Teki
---
Goodix CTP controllers have AVDD28 pin connected to voltage
regulator which may not be turned on by default, like for GT5663.
Add support for such ctp used boards by adding voltage regulator
handling code to goodix ctp driver.
Signed-off-by: Jagan Teki
---
Changes for v2:
- disable regulator in
GT5663 is capacitive touch controller with customized smart
wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum
Goodix CTP controllers have AVDD28 pin connected to voltage
regulator which may not be turned on by default, like for GT5663.
Add support for such ctp used boards by adding voltage regulator
handling code to goodix ctp driver.
Signed-off-by: Jagan Teki
---
Changes for v2:
- disable regulator in
GT5663 is capacitive touch controller with customized smart
wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum
On Wed, Dec 5, 2018 at 3:36 PM Andrea Arcangeli wrote:
>
> Like said earlier still better to apply __GFP_COMPACT_ONLY or David's
> patch than to return to v4.18 though.
Ok, I've applied David's latest patch.
I'm not at all objecting to tweaking this further, I just didn't want
to have this
From: "Steven Rostedt (VMware)"
Commit 588ca1786f2dd ("function_graph: Use new curr_ret_depth to manage
depth instead of curr_ret_stack") removed a parameter from the call
ftrace_push_return_trace() that made it so that the entire call was under 80
characters, but it did not remove the line
From: "Steven Rostedt (VMware)"
Commit 588ca1786f2dd ("function_graph: Use new curr_ret_depth to manage
depth instead of curr_ret_stack") removed a parameter from the call
ftrace_push_return_trace() that made it so that the entire call was under 80
characters, but it did not remove the line
On Wed, Dec 5, 2018 at 3:36 PM Andrea Arcangeli wrote:
>
> Like said earlier still better to apply __GFP_COMPACT_ONLY or David's
> patch than to return to v4.18 though.
Ok, I've applied David's latest patch.
I'm not at all objecting to tweaking this further, I just didn't want
to have this
From: "Steven Rostedt (VMware)"
The static inline function task_curr_ret_stack() is unused, remove it.
Reviewed-by: Joel Fernandes (Google)
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ftrace.h | 10 --
1 file changed, 10 deletions(-)
diff
Note, I still have more in my queue that need to go through testing.
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next
Head SHA1: e007f5165a2e366579324062a69e56236a97fad3
Dan Carpenter (1):
tracing: Have trace_stack nr_entries compare not be so subtle
Joe
From: "Steven Rostedt (VMware)"
As the function graph infrastructure can be used by thing other than
tracing, moving the code to its own file out of the trace_functions_graph.c
code makes more sense.
The fgraph.c file will only contain the infrastructure required to hook into
functions and
From: "Steven Rostedt (VMware)"
The static inline function task_curr_ret_stack() is unused, remove it.
Reviewed-by: Joel Fernandes (Google)
Reviewed-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
include/linux/ftrace.h | 10 --
1 file changed, 10 deletions(-)
diff
Note, I still have more in my queue that need to go through testing.
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next
Head SHA1: e007f5165a2e366579324062a69e56236a97fad3
Dan Carpenter (1):
tracing: Have trace_stack nr_entries compare not be so subtle
Joe
From: "Steven Rostedt (VMware)"
As the function graph infrastructure can be used by thing other than
tracing, moving the code to its own file out of the trace_functions_graph.c
code makes more sense.
The fgraph.c file will only contain the infrastructure required to hook into
functions and
From: "Steven Rostedt (VMware)"
In order to make the function graph infrastructure more generic, there can
not be code specific for the function_graph tracer in the generic code. This
includes the set_graph_notrace logic, that stops all graph calls when a
function in the set_graph_notrace is
From: "Steven Rostedt (VMware)"
Currently the registering of function graph is to pass in a entry and return
function. We need to have a way to associate those functions together where
the entry can determine to run the return hook. Having a structure that
contains both functions will facilitate
From: "Steven Rostedt (VMware)"
Move the function function_graph_ret_addr() to fgraph.c, as the management
of the curr_ret_stack is going to change, and all the accesses to ret_stack
needs to be done in fgraph.c.
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Steven Rostedt (VMware)
---
From: Dan Carpenter
Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
one bug.
"From reviewing the code, it seems possible for
stack_trace_max.nr_entries to be set to .max_entries and in that case we
would be reading one element beyond the end of the
From: "Steven Rostedt (VMware)"
Add a "buffer_percentage" file, that allows users to specify how much of the
buffer (percentage of pages) need to be filled before waking up a task
blocked on a per cpu trace_pipe_raw file.
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/ring_buffer.c |
From: "Steven Rostedt (VMware)"
In order to move function graph infrastructure into its own file (fgraph.h)
it needs to access various functions and variables in ftrace.c that are
currently static. Create a new file called ftrace-internal.h that holds the
function prototypes and the extern
From: "Steven Rostedt (VMware)"
To make the function graph infrastructure more managable, the code needs to
be in its own file (fgraph.c). Move the code that is specific for managing
the function graph infrastructure out of ftrace.c and into fgraph.c
Reviewed-by: Joel Fernandes (Google)
From: "Steven Rostedt (VMware)"
The curr_ret_stack is no longer set to a negative value when a function is
not to be traced by the function graph tracer. Remove the usage of
FTRACE_NOTRACE_DEPTH, as it is no longer needed.
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Steven Rostedt
From: "Steven Rostedt (VMware)"
In order to make the function graph infrastructure more generic, there can
not be code specific for the function_graph tracer in the generic code. This
includes the set_graph_notrace logic, that stops all graph calls when a
function in the set_graph_notrace is
From: "Steven Rostedt (VMware)"
Currently the registering of function graph is to pass in a entry and return
function. We need to have a way to associate those functions together where
the entry can determine to run the return hook. Having a structure that
contains both functions will facilitate
From: "Steven Rostedt (VMware)"
Move the function function_graph_ret_addr() to fgraph.c, as the management
of the curr_ret_stack is going to change, and all the accesses to ret_stack
needs to be done in fgraph.c.
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Steven Rostedt (VMware)
---
From: Dan Carpenter
Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
one bug.
"From reviewing the code, it seems possible for
stack_trace_max.nr_entries to be set to .max_entries and in that case we
would be reading one element beyond the end of the
From: "Steven Rostedt (VMware)"
Add a "buffer_percentage" file, that allows users to specify how much of the
buffer (percentage of pages) need to be filled before waking up a task
blocked on a per cpu trace_pipe_raw file.
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/ring_buffer.c |
From: "Steven Rostedt (VMware)"
In order to move function graph infrastructure into its own file (fgraph.h)
it needs to access various functions and variables in ftrace.c that are
currently static. Create a new file called ftrace-internal.h that holds the
function prototypes and the extern
From: "Steven Rostedt (VMware)"
To make the function graph infrastructure more managable, the code needs to
be in its own file (fgraph.c). Move the code that is specific for managing
the function graph infrastructure out of ftrace.c and into fgraph.c
Reviewed-by: Joel Fernandes (Google)
From: "Steven Rostedt (VMware)"
The curr_ret_stack is no longer set to a negative value when a function is
not to be traced by the function graph tracer. Remove the usage of
FTRACE_NOTRACE_DEPTH, as it is no longer needed.
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Steven Rostedt
From: Masami Hiramatsu
Use dyn_event framework for kprobe events. This shows
kprobe events on "tracing/dynamic_events" file.
User can also define new events via tracing/dynamic_events.
Link:
http://lkml.kernel.org/r/154140855646.17322.6619219995865980392.stgit@devbox
Reviewed-by: Tom Zanussi
From: "Steven Rostedt (VMware)"
Rearrange the functions in trace_sched_wakeup.c so that there are fewer
#ifdef CONFIG_FUNCTION_TRACER and #ifdef CONFIG_FUNCTION_GRAPH_TRACER,
instead of having the #ifdefs spread all over.
No functional change is made.
Signed-off-by: Steven Rostedt (VMware)
From: Masami Hiramatsu
Integrate similar argument parsers for kprobes and uprobes events
into traceprobe_parse_probe_arg().
Link:
http://lkml.kernel.org/r/154140850016.17322.9836787731210512176.stgit@devbox
Reviewed-by: Tom Zanussi
Tested-by: Tom Zanussi
Signed-off-by: Masami Hiramatsu
From: Masami Hiramatsu
Add a busy check loop in cleanup_all_probes() before
trying to remove all events in uprobe_events, the same way
that kprobe_events does.
Without this change, writing null to uprobe_events will
try to remove events but if one of them is enabled, it will
stop there leaving
From: Joe Lawrence
When building with -ffunction-sections, the compiler will place each
function into its own ELF section, prefixed with ".text". For example,
a simple test module with functions test_module_do_work() and
test_module_wq_func():
% objdump --section-headers test_module.o | awk
From: "Steven Rostedt (VMware)"
After running several tests, it appears that having the reader wait till
half the buffer is full before starting to read (and causing its own events
to fill up the ring buffer constantly), works well. It keeps trace-cmd (the
main user of this interface) from
From: "Steven Rostedt (VMware)"
After running several tests, it appears that having the reader wait till
half the buffer is full before starting to read (and causing its own events
to fill up the ring buffer constantly), works well. It keeps trace-cmd (the
main user of this interface) from
From: Masami Hiramatsu
Use dyn_event framework for kprobe events. This shows
kprobe events on "tracing/dynamic_events" file.
User can also define new events via tracing/dynamic_events.
Link:
http://lkml.kernel.org/r/154140855646.17322.6619219995865980392.stgit@devbox
Reviewed-by: Tom Zanussi
From: "Steven Rostedt (VMware)"
Rearrange the functions in trace_sched_wakeup.c so that there are fewer
#ifdef CONFIG_FUNCTION_TRACER and #ifdef CONFIG_FUNCTION_GRAPH_TRACER,
instead of having the #ifdefs spread all over.
No functional change is made.
Signed-off-by: Steven Rostedt (VMware)
From: Masami Hiramatsu
Integrate similar argument parsers for kprobes and uprobes events
into traceprobe_parse_probe_arg().
Link:
http://lkml.kernel.org/r/154140850016.17322.9836787731210512176.stgit@devbox
Reviewed-by: Tom Zanussi
Tested-by: Tom Zanussi
Signed-off-by: Masami Hiramatsu
From: Masami Hiramatsu
Add a busy check loop in cleanup_all_probes() before
trying to remove all events in uprobe_events, the same way
that kprobe_events does.
Without this change, writing null to uprobe_events will
try to remove events but if one of them is enabled, it will
stop there leaving
From: Joe Lawrence
When building with -ffunction-sections, the compiler will place each
function into its own ELF section, prefixed with ".text". For example,
a simple test module with functions test_module_do_work() and
test_module_wq_func():
% objdump --section-headers test_module.o | awk
From: Masami Hiramatsu
Add a generic method to remove event from dynamic event
list. This is same as other system under ftrace. You
just need to pass the event name with '!', e.g.
# echo p:new_grp/new_event _do_fork > dynamic_events
This creates an event, and
# echo '!p:new_grp/new_event
From: "Steven Rostedt (VMware)"
Instead of just waiting for a page to be full before waking up a pending
reader, allow the reader to pass in a "percentage" of pages that have
content before waking up a reader. This should help keep the process of
reading the events not cause wake ups that
From: "Steven Rostedt (VMware)"
When the function profiler is not configured, the "graph_time" option is
meaningless, as the function profiler is the only thing that makes use of
it. Do not expose it if the profiler is not configured.
Link:
From: Masami Hiramatsu
Rmove unneeded synth_event_mutex. This mutex protects the reference
count in synth_event, however, those operational points are already
protected by event_mutex.
1. In __create_synth_event() and create_or_delete_synth_event(),
those synth_event_mutex clearly obtained
From: "Steven Rostedt (VMware)"
The ret_stack processing is going to change, and that is going
to break anything that is accessing the ret_stack directly. One user is the
function graph profiler. By using the ftrace_graph_get_ret_stack() helper
function, the profiler can access the ret_stack
From: Masami Hiramatsu
Use dyn_event framework for synthetic events. This shows
synthetic events on "tracing/dynamic_events" file in addition
to tracing/synthetic_events interface.
User can also define new events via tracing/dynamic_events
with "s:" prefix. So, the new syntax is below;
From: Masami Hiramatsu
Since the event_mutex and synth_event_mutex ordering issue
is gone, we can skip existing event check when adding or
deleting events, and some redundant code in error path.
This changes release_all_synth_events() to abort the process
when it hits any error and returns the
From: Masami Hiramatsu
synthetic event is using synth_event_mutex for protecting
synth_event_list, and event_trigger_write() path acquires
locks as below order.
event_trigger_write(event_mutex)
->trigger_process_regex(trigger_cmd_mutex)
->event_hist_trigger_func(synth_event_mutex)
On the
From: Masami Hiramatsu
Add common testcases for dynamic_events interface.
- Add/remove kprobe events via dynamic_events
- Add/remove synthetic events via dynamic_events
- Selective clear events (clear events other interfaces)
- Genelic clear events ("!LINE" syntax)
Link:
From: Masami Hiramatsu
Rmove unneeded synth_event_mutex. This mutex protects the reference
count in synth_event, however, those operational points are already
protected by event_mutex.
1. In __create_synth_event() and create_or_delete_synth_event(),
those synth_event_mutex clearly obtained
From: "Steven Rostedt (VMware)"
The ret_stack processing is going to change, and that is going
to break anything that is accessing the ret_stack directly. One user is the
function graph profiler. By using the ftrace_graph_get_ret_stack() helper
function, the profiler can access the ret_stack
From: Masami Hiramatsu
Use dyn_event framework for synthetic events. This shows
synthetic events on "tracing/dynamic_events" file in addition
to tracing/synthetic_events interface.
User can also define new events via tracing/dynamic_events
with "s:" prefix. So, the new syntax is below;
From: Masami Hiramatsu
Since the event_mutex and synth_event_mutex ordering issue
is gone, we can skip existing event check when adding or
deleting events, and some redundant code in error path.
This changes release_all_synth_events() to abort the process
when it hits any error and returns the
From: Masami Hiramatsu
synthetic event is using synth_event_mutex for protecting
synth_event_list, and event_trigger_write() path acquires
locks as below order.
event_trigger_write(event_mutex)
->trigger_process_regex(trigger_cmd_mutex)
->event_hist_trigger_func(synth_event_mutex)
On the
From: Masami Hiramatsu
Add common testcases for dynamic_events interface.
- Add/remove kprobe events via dynamic_events
- Add/remove synthetic events via dynamic_events
- Selective clear events (clear events other interfaces)
- Genelic clear events ("!LINE" syntax)
Link:
From: Masami Hiramatsu
Add a generic method to remove event from dynamic event
list. This is same as other system under ftrace. You
just need to pass the event name with '!', e.g.
# echo p:new_grp/new_event _do_fork > dynamic_events
This creates an event, and
# echo '!p:new_grp/new_event
301 - 400 of 2376 matches
Mail list logo
