[tip:perf/core] tools lib traceevent: Add pevent_print_func_field () helper function
Commit-ID: 6d862b8c14ba539c7c87ffc77f2e1d6dc9630c4d
Gitweb: http://git.kernel.org/tip/6d862b8c14ba539c7c87ffc77f2e1d6dc9630c4d
Author: Steven Rostedt
AuthorDate: Fri, 1 Nov 2013 17:54:00 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 14:36:49 -0300
tools lib traceevent: Add pevent_print_func_field() helper function
Add the pevent_print_func_field() that will look up a field that is
expected to be a function pointer, and it will print the function name
and offset of the address given by the field.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215501.869542...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 42 ++
tools/lib/traceevent/event-parse.h | 4
2 files changed, 46 insertions(+)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index fc6f35f..8f450ad 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -5367,6 +5367,48 @@ int pevent_print_num_field(struct trace_seq *s, const
char *fmt,
return -1;
}
+/**
+ * pevent_print_func_field - print a field and a format for function pointers
+ * @s: The seq to print to
+ * @fmt: The printf format to print the field with.
+ * @event: the event that the field is for
+ * @name: The name of the field
+ * @record: The record with the field name.
+ * @err: print default error if failed.
+ *
+ * Returns: 0 on success, -1 field not found, or 1 if buffer is full.
+ */
+int pevent_print_func_field(struct trace_seq *s, const char *fmt,
+ struct event_format *event, const char *name,
+ struct pevent_record *record, int err)
+{
+ struct format_field *field = pevent_find_field(event, name);
+ struct pevent *pevent = event->pevent;
+ unsigned long long val;
+ struct func_map *func;
+ char tmp[128];
+
+ if (!field)
+ goto failed;
+
+ if (pevent_read_number_field(field, record->data, ))
+ goto failed;
+
+ func = find_func(pevent, val);
+
+ if (func)
+ snprintf(tmp, 128, "%s/0x%llx", func->func, func->addr - val);
+ else
+ sprintf(tmp, "0x%08llx", val);
+
+ return trace_seq_printf(s, fmt, tmp);
+
+ failed:
+ if (err)
+ trace_seq_printf(s, "CAN'T FIND FIELD \"%s\"", name);
+ return -1;
+}
+
static void free_func_handle(struct pevent_function_handler *func)
{
struct pevent_func_params *params;
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index dc8539e..8d73d25 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -569,6 +569,10 @@ int pevent_print_num_field(struct trace_seq *s, const char
*fmt,
struct event_format *event, const char *name,
struct pevent_record *record, int err);
+int pevent_print_func_field(struct trace_seq *s, const char *fmt,
+ struct event_format *event, const char *name,
+ struct pevent_record *record, int err);
+
int pevent_register_event_handler(struct pevent *pevent, int id,
const char *sys_name, const char *event_name,
pevent_event_handler_func func, void
*context);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib traceevent: Handle __print_hex( __get_dynamic_array(fieldname), len)
Commit-ID: b30f75eba27a9ab0704cbc501e9be3b025ce56fe
Gitweb: http://git.kernel.org/tip/b30f75eba27a9ab0704cbc501e9be3b025ce56fe
Author: Howard Cochran
AuthorDate: Fri, 1 Nov 2013 17:53:56 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 14:34:43 -0300
tools lib traceevent: Handle __print_hex(__get_dynamic_array(fieldname), len)
The kernel has a few events with a format similar to this excerpt:
field:unsigned int len; offset:12; size:4; signed:0;
field:__data_loc unsigned char[] data_array; offset:16; size:4;
signed:0;
print fmt: "%s", __print_hex(__get_dynamic_array(data_array), REC->len)
trace-cmd could already parse that arg correctly, but print_str_arg()
was unable to handle the first parameter being a dynamic array. (It
just printed a "field not found" warning).
Teach print_str_arg's PRINT_HEX case to handle the nested
PRINT_DYNAMIC_ARRAY correctly. The output now matches the kernel's own
formatting for this case.
Signed-off-by: Howard Cochran
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1381503349-12271-1-git-send-email-hcoch...@lexmark.com
[ Removed "polish compare", we don't do that here ]
Signed-off-by: Steven Rostedt
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 013c8d3..0a1ffe0 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3588,15 +3588,23 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
}
break;
case PRINT_HEX:
- field = arg->hex.field->field.field;
- if (!field) {
- str = arg->hex.field->field.name;
- field = pevent_find_any_field(event, str);
- if (!field)
- goto out_warning_field;
- arg->hex.field->field.field = field;
+ if (arg->hex.field->type == PRINT_DYNAMIC_ARRAY) {
+ unsigned long offset;
+ offset = pevent_read_number(pevent,
+ data + arg->hex.field->dynarray.field->offset,
+ arg->hex.field->dynarray.field->size);
+ hex = data + (offset & 0x);
+ } else {
+ field = arg->hex.field->field.field;
+ if (!field) {
+ str = arg->hex.field->field.name;
+ field = pevent_find_any_field(event, str);
+ if (!field)
+ goto out_warning_field;
+ arg->hex.field->field.field = field;
+ }
+ hex = data + field->offset;
}
- hex = data + field->offset;
len = eval_num_arg(data, size, event, arg->hex.size);
for (i = 0; i < len; i++) {
if (i)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib traceevent: Update printk formats when entered
Commit-ID: 18900af8292180151c82f0762506fa0740aa54a5
Gitweb: http://git.kernel.org/tip/18900af8292180151c82f0762506fa0740aa54a5
Author: Steven Rostedt (Red Hat)
AuthorDate: Fri, 1 Nov 2013 17:53:54 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 14:33:59 -0300
tools lib traceevent: Update printk formats when entered
Instead of cropping off the '"' and '\n"' from a printk format every
time it is referenced, do it when it's added. This makes it easier to
reference a printk_map and should speed things up a little.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215500.495619...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 29 ++---
tools/lib/traceevent/event-parse.h | 2 +-
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index deedff9..856b791 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -604,10 +604,11 @@ find_printk(struct pevent *pevent, unsigned long long
addr)
* This registers a string by the address it was stored in the kernel.
* The @fmt passed in is duplicated.
*/
-int pevent_register_print_string(struct pevent *pevent, char *fmt,
+int pevent_register_print_string(struct pevent *pevent, const char *fmt,
unsigned long long addr)
{
struct printk_list *item = malloc(sizeof(*item));
+ char *p;
if (!item)
return -1;
@@ -615,10 +616,21 @@ int pevent_register_print_string(struct pevent *pevent,
char *fmt,
item->next = pevent->printklist;
item->addr = addr;
+ /* Strip off quotes and '\n' from the end */
+ if (fmt[0] == '"')
+ fmt++;
item->printk = strdup(fmt);
if (!item->printk)
goto out_free;
+ p = item->printk + strlen(item->printk) - 1;
+ if (*p == '"')
+ *p = 0;
+
+ p -= 2;
+ if (strcmp(p, "\\n") == 0)
+ *p = 0;
+
pevent->printklist = item;
pevent->printk_count++;
@@ -3887,7 +3899,6 @@ get_bprint_format(void *data, int size __maybe_unused,
struct format_field *field;
struct printk_map *printk;
char *format;
- char *p;
field = pevent->bprint_fmt_field;
@@ -3909,20 +3920,8 @@ get_bprint_format(void *data, int size __maybe_unused,
return format;
}
- p = printk->printk;
- /* Remove any quotes. */
- if (*p == '"')
- p++;
- if (asprintf(, "%s : %s", "%pf", p) < 0)
+ if (asprintf(, "%s : %s", "%pf", printk->printk) < 0)
return NULL;
- /* remove ending quotes and new line since we will add one too */
- p = format + strlen(format) - 1;
- if (*p == '"')
- *p = 0;
-
- p -= 2;
- if (strcmp(p, "\\n") == 0)
- *p = 0;
return format;
}
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index 7503edf..9ab6367 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -533,7 +533,7 @@ int pevent_register_comm(struct pevent *pevent, const char
*comm, int pid);
void pevent_register_trace_clock(struct pevent *pevent, char *trace_clock);
int pevent_register_function(struct pevent *pevent, char *name,
unsigned long long addr, char *mod);
-int pevent_register_print_string(struct pevent *pevent, char *fmt,
+int pevent_register_print_string(struct pevent *pevent, const char *fmt,
unsigned long long addr);
int pevent_pid_is_registered(struct pevent *pevent, int pid);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib traceevent: Check for spaces in character array
Commit-ID: 5efb9fbd5f1bfe4435bd0a3ea5f0e187875509c2 Gitweb: http://git.kernel.org/tip/5efb9fbd5f1bfe4435bd0a3ea5f0e187875509c2 Author: Steven Rostedt (Red Hat) AuthorDate: Fri, 1 Nov 2013 17:53:58 -0400 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 4 Nov 2013 14:35:54 -0300 tools lib traceevent: Check for spaces in character array Currently when using the raw format for fields, when looking at a character array, to determine if it is a string or not, we make sure all characters are "isprint()". If not, then we consider it a numeric array, and print the hex numbers of the characters instead. But it seems that '\n' fails the isprint() check! Add isspace() to the check as well, such that if all characters pass isprint() or isspace() it will assume the character array is a string. Reported-by: Xenia Ragiadakou Signed-off-by: Steven Rostedt Cc: Andrew Morton Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Xenia Ragiadakou Link: http://lkml.kernel.org/r/20131101215501.465091...@goodmis.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/lib/traceevent/event-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c index e1c743c..85cbbdd 100644 --- a/tools/lib/traceevent/event-parse.c +++ b/tools/lib/traceevent/event-parse.c @@ -3981,7 +3981,7 @@ static int is_printable_array(char *p, unsigned int len) unsigned int i; for (i = 0; i < len && p[i]; i++) - if (!isprint(p[i])) + if (!isprint(p[i]) && !isspace(p[i])) return 0; return 1; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Solving M produces N consumers scalability problem
Hi Thanks for your reply On Mon, Nov 4, 2013 at 10:53 AM, Andi Kleen wrote: > Anatol Pomozov writes: >> >> One idea is not to use the spin_lock. It is the 'fair spin_lock' that >> has scalability problems >> http://pdos.csail.mit.edu/papers/linux:lock.pdf Maybe lockless >> datastructures can help here? > > The standard spin lock is already improved. > But better locks just give you a small advantage, they don't > solve the real scaling problem. Do you know in what version the improvement happened? I use kernel 3.3 and I can backport the changes to my custom kernel to make the situation better. >> Another idea is avoid global datasctructures but I have a few >> questions here. Let's say we want to use per-CPU lists. But the >> problem is that producers/consumers are not distributed across all >> CPUs. Some CPU might have too many producers, some other might not >> have consumers at all. So we need some kind of migration from hot CPU >> to the cold one. What is the best way to achieve it? Are there any >> examples how to do this? Any other ideas? > > per cpu is the standard approach, but usually overkill. Also > requires complex code to drain etc. > > Some older patches also use per node, but that works very poorly > these days (nodes are far too big) > > One way I like is to simply use a global (allocated) array of queues, > sized by total number of possible cpus (but significantly smaller) and > use the cpu number as a hash into the array. This solution pretty-much equivalent to per-CPU data structures. And in this case there also will be "hot" nodes and "cold" nodes. So my question remains - what is the best way to implement data migration between nodes, is there a standard solution for this? examples? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib traceevent: Add flags NOHANDLE and PRINTRAW to individual events
Commit-ID: c6c2b960b7a4105f096499fba3df65d6c0272a20
Gitweb: http://git.kernel.org/tip/c6c2b960b7a4105f096499fba3df65d6c0272a20
Author: Steven Rostedt
AuthorDate: Fri, 1 Nov 2013 17:53:59 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 14:36:27 -0300
tools lib traceevent: Add flags NOHANDLE and PRINTRAW to individual events
Add the flags EVENT_FL_NOHANDLE and EVENT_FL_PRINTRAW to the event flags
to have the event either ignore the register handler or to ignore the
handler and also print the raw format respectively.
This allows a tool to force a raw format or non handle for an event.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215501.655258...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 4 ++--
tools/lib/traceevent/event-parse.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 85cbbdd..fc6f35f 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -4446,11 +4446,11 @@ void pevent_event_info(struct trace_seq *s, struct
event_format *event,
{
int print_pretty = 1;
- if (event->pevent->print_raw)
+ if (event->pevent->print_raw || (event->flags & EVENT_FL_PRINTRAW))
print_event_fields(s, record->data, record->size, event);
else {
- if (event->handler)
+ if (event->handler && !(event->flags & EVENT_FL_NOHANDLE))
print_pretty = event->handler(s, record, event,
event->context);
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index 9ab6367..dc8539e 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -308,6 +308,8 @@ enum {
EVENT_FL_ISBPRINT = 0x04,
EVENT_FL_ISFUNCENT = 0x10,
EVENT_FL_ISFUNCRET = 0x20,
+ EVENT_FL_NOHANDLE = 0x40,
+ EVENT_FL_PRINTRAW = 0x80,
EVENT_FL_FAILED = 0x8000
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib traceevent: If %s is a pointer, check printk formats
Commit-ID: 0970b5f438261216afcd0ccaa2fcfffc83df7ca2
Gitweb: http://git.kernel.org/tip/0970b5f438261216afcd0ccaa2fcfffc83df7ca2
Author: Steven Rostedt (Red Hat)
AuthorDate: Fri, 1 Nov 2013 17:53:55 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 14:34:26 -0300
tools lib traceevent: If %s is a pointer, check printk formats
If the format string of TP_printk() contains a %s, and the argument is
not a string, check if the argument is a pointer that might match the
printk_formats that were stored.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215500.698924...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 856b791..013c8d3 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3505,6 +3505,7 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
struct pevent *pevent = event->pevent;
struct print_flag_sym *flag;
struct format_field *field;
+ struct printk_map *printk;
unsigned long long val, fval;
unsigned long addr;
char *str;
@@ -3540,7 +3541,12 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
if (!(field->flags & FIELD_IS_ARRAY) &&
field->size == pevent->long_size) {
addr = *(unsigned long *)(data + field->offset);
- trace_seq_printf(s, "%lx", addr);
+ /* Check if it matches a print format */
+ printk = find_printk(pevent, addr);
+ if (printk)
+ trace_seq_puts(s, printk->printk);
+ else
+ trace_seq_printf(s, "%lx", addr);
break;
}
str = malloc(len + 1);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf evsel: Synthesize PERF_SAMPLE_TRANSACTION
Commit-ID: 42d88910c717ba21089251d0ca559abfef0df22d
Gitweb: http://git.kernel.org/tip/42d88910c717ba21089251d0ca559abfef0df22d
Author: Adrian Hunter
AuthorDate: Fri, 1 Nov 2013 15:51:38 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:49:36 -0300
perf evsel: Synthesize PERF_SAMPLE_TRANSACTION
Add missing PERF_SAMPLE_TRANSACTION to perf_event__synthesize_sample()
and perf_event__sample_event_size().
This makes the "sample parsing" test pass.
Signed-off-by: Adrian Hunter
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-11-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index b121717..5280820 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1578,6 +1578,9 @@ size_t perf_event__sample_event_size(const struct
perf_sample *sample, u64 type,
if (type & PERF_SAMPLE_DATA_SRC)
result += sizeof(u64);
+ if (type & PERF_SAMPLE_TRANSACTION)
+ result += sizeof(u64);
+
return result;
}
@@ -1751,6 +1754,11 @@ int perf_event__synthesize_sample(union perf_event
*event, u64 type,
array++;
}
+ if (type & PERF_SAMPLE_TRANSACTION) {
+ *array = sample->transaction;
+ array++;
+ }
+
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf top: Use parse_options_usage() for -s option failure
Commit-ID: d37a92dcb45094dc02836c8a77c693c6f9916fb2
Gitweb: http://git.kernel.org/tip/d37a92dcb45094dc02836c8a77c693c6f9916fb2
Author: Namhyung Kim
AuthorDate: Fri, 1 Nov 2013 16:33:14 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:56:41 -0300
perf top: Use parse_options_usage() for -s option failure
The -s (--sort) option was processed after normal option parsing so that
it cannot call the parse_options_usage() automatically. Currently it
calls usage_with_options() which shows entire help messages for event
option. Fix it by showing just -s options.
$ perf top -s help
Error: Unknown --sort key: `help'
usage: perf top []
-s, --sort
sort by key(s): pid, comm, dso, symbol, ...
Signed-off-by: Namhyung Kim
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-5-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-top.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 21db76d..ca5ca37 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1040,7 +1040,7 @@ parse_percent_limit(const struct option *opt, const char
*arg,
int cmd_top(int argc, const char **argv, const char *prefix __maybe_unused)
{
- int status;
+ int status = -1;
char errbuf[BUFSIZ];
struct perf_top top = {
.count_filter= 5,
@@ -1159,8 +1159,10 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
if (sort_order == default_sort_order)
sort_order = "dso,symbol";
- if (setup_sorting() < 0)
- usage_with_options(top_usage, options);
+ if (setup_sorting() < 0) {
+ parse_options_usage(top_usage, options, "s", 1);
+ goto out_delete_evlist;
+ }
/* display thread wants entries to be collapsed in a different tree */
sort__need_collapse = 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf evlist: Add a debug print if event buffer mmap fails
Commit-ID: 026359658aecd348bc5c4a136a26f204b169103b
Gitweb: http://git.kernel.org/tip/026359658aecd348bc5c4a136a26f204b169103b
Author: Adrian Hunter
AuthorDate: Fri, 1 Nov 2013 15:51:33 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:21:41 -0300
perf evlist: Add a debug print if event buffer mmap fails
Add a debug print if mmap of the perf event ring buffer fails.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-6-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 0582f67..1c173cc 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -607,6 +607,8 @@ static int __perf_evlist__mmap(struct perf_evlist *evlist,
evlist->mmap[idx].base = mmap(NULL, evlist->mmap_len, prot,
MAP_SHARED, fd, 0);
if (evlist->mmap[idx].base == MAP_FAILED) {
+ pr_debug2("failed to mmap perf event ring buffer, error %d\n",
+ errno);
evlist->mmap[idx].base = NULL;
return -1;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf stat: Enhance option parse error message
Commit-ID: cc03c54296ccbeca5363dfe8f49af42d14960f28
Gitweb: http://git.kernel.org/tip/cc03c54296ccbeca5363dfe8f49af42d14960f28
Author: Namhyung Kim
AuthorDate: Fri, 1 Nov 2013 16:33:15 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:57:36 -0300
perf stat: Enhance option parse error message
Print related option help messages only when it failed to process
options. While at it, modify parse_options_usage() to skip usage part
so that it can be used for showing multiple option help messages
naturally like below:
$ perf stat -Bx, ls
-B option not supported with -x
usage: perf stat [] []
-B, --big-num print large numbers with thousands' separators
-x, --field-separator
print counts with custom separator
Signed-off-by: Namhyung Kim
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-6-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 42 ++---
tools/perf/util/parse-options.c | 3 ++-
2 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 1a9c95d..0fc1c94 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1596,7 +1596,7 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
"perf stat [] []",
NULL
};
- int status = -ENOMEM, run_idx;
+ int status = -EINVAL, run_idx;
const char *mode;
setlocale(LC_ALL, "");
@@ -1614,12 +1614,15 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
if (output_name && output_fd) {
fprintf(stderr, "cannot use both --output and --log-fd\n");
- usage_with_options(stat_usage, options);
+ parse_options_usage(stat_usage, options, "o", 1);
+ parse_options_usage(NULL, options, "log-fd", 0);
+ goto out;
}
if (output_fd < 0) {
fprintf(stderr, "argument to --log-fd must be a > 0\n");
- usage_with_options(stat_usage, options);
+ parse_options_usage(stat_usage, options, "log-fd", 0);
+ goto out;
}
if (!output) {
@@ -1656,7 +1659,9 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
/* User explicitly passed -B? */
if (big_num_opt == 1) {
fprintf(stderr, "-B option not supported with -x\n");
- usage_with_options(stat_usage, options);
+ parse_options_usage(stat_usage, options, "B", 1);
+ parse_options_usage(NULL, options, "x", 1);
+ goto out;
} else /* Nope, so disable big number formatting */
big_num = false;
} else if (big_num_opt == 0) /* User passed --no-big-num */
@@ -1666,7 +1671,9 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
usage_with_options(stat_usage, options);
if (run_count < 0) {
- usage_with_options(stat_usage, options);
+ pr_err("Run count must be a positive number\n");
+ parse_options_usage(stat_usage, options, "r", 1);
+ goto out;
} else if (run_count == 0) {
forever = true;
run_count = 1;
@@ -1678,8 +1685,10 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
fprintf(stderr, "both cgroup and no-aggregation "
"modes only available in system-wide mode\n");
- usage_with_options(stat_usage, options);
- return -1;
+ parse_options_usage(stat_usage, options, "G", 1);
+ parse_options_usage(NULL, options, "A", 1);
+ parse_options_usage(NULL, options, "a", 1);
+ goto out;
}
if (add_default_attributes())
@@ -1688,25 +1697,28 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
perf_target__validate();
if (perf_evlist__create_maps(evsel_list, ) < 0) {
- if (perf_target__has_task())
+ if (perf_target__has_task()) {
pr_err("Problems finding threads of monitor\n");
- if (perf_target__has_cpu())
+ parse_options_usage(stat_usage, options, "p", 1);
+ parse_options_usage(NULL, options, "t", 1);
+ } else if (perf_target__has_cpu()) {
perror("failed to parse CPUs map");
-
-
[tip:perf/core] perf evsel: Add missing overflow check for TRANSACTION
Commit-ID: 87b955247d71975460774435241be3aa05218a7b
Gitweb: http://git.kernel.org/tip/87b955247d71975460774435241be3aa05218a7b
Author: Adrian Hunter
AuthorDate: Fri, 1 Nov 2013 15:51:36 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:44:01 -0300
perf evsel: Add missing overflow check for TRANSACTION
Add missing overflow check for PERF_SAMPLE_TRANSACTION in
perf_evsel__parse_sample().
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-9-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 47bbf03..b121717 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1481,6 +1481,7 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
data->transaction = 0;
if (type & PERF_SAMPLE_TRANSACTION) {
+ OVERFLOW_CHECK_u64(array);
data->transaction = *array;
array++;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf test: Update "sample parsing" test for PERF_SAMPLE_TRANSACTION
Commit-ID: 091a4ef5a94d46d26a05f0c32d2f64800ed91306
Gitweb: http://git.kernel.org/tip/091a4ef5a94d46d26a05f0c32d2f64800ed91306
Author: Adrian Hunter
AuthorDate: Fri, 1 Nov 2013 15:51:37 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:47:24 -0300
perf test: Update "sample parsing" test for PERF_SAMPLE_TRANSACTION
In fact the "sample parsing" test does not automatically check new
sample type bits - they must be added to the comparison logic.
Doing that shows that the test fails because the functions
perf_event__synthesize_sample() and perf_event__sample_event_size() have
not been updated with PERF_SAMPLE_TRANSACTION either.
Signed-off-by: Adrian Hunter
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-10-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/sample-parsing.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/sample-parsing.c
b/tools/perf/tests/sample-parsing.c
index 61c9da2..1b67720 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -121,6 +121,9 @@ static bool samples_same(const struct perf_sample *s1,
if (type & PERF_SAMPLE_DATA_SRC)
COMP(data_src);
+ if (type & PERF_SAMPLE_TRANSACTION)
+ COMP(transaction);
+
return true;
}
@@ -165,6 +168,7 @@ static int do_test(u64 sample_type, u64 sample_regs_user,
u64 read_format)
.cpu= 110,
.raw_size = sizeof(raw_data),
.data_src = 111,
+ .transaction= 112,
.raw_data = (void *)raw_data,
.callchain = ,
.branch_stack = _stack.branch_stack,
@@ -273,7 +277,8 @@ int test__sample_parsing(void)
/*
* Fail the test if it has not been updated when new sample format bits
-* were added.
+* were added. Please actually update the test rather than just change
+* the condition below.
*/
if (PERF_SAMPLE_MAX > PERF_SAMPLE_TRANSACTION << 1) {
pr_debug("sample format has changed, some new PERF_SAMPLE_ bit
was introduced - test needs updating\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf evsel: Always use perf_evsel__set_sample_bit ()
Commit-ID: 1e7ed5ec54e3998bda6ea625599a0644404cb421
Gitweb: http://git.kernel.org/tip/1e7ed5ec54e3998bda6ea625599a0644404cb421
Author: Adrian Hunter
AuthorDate: Fri, 1 Nov 2013 15:51:35 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:42:28 -0300
perf evsel: Always use perf_evsel__set_sample_bit()
Always use perf_evsel__set_sample_bit() rather than just setting the
bit.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-8-git-send-email-adrian.hun...@intel.com
[ Cope with 3090ffb "perf: Disable PERF_RECORD_MMAP2 support" ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index f0e65de..47bbf03 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -663,7 +663,7 @@ void perf_evsel__config(struct perf_evsel *evsel,
}
if (opts->sample_address)
- attr->sample_type |= PERF_SAMPLE_DATA_SRC;
+ perf_evsel__set_sample_bit(evsel, DATA_SRC);
if (opts->no_delay) {
attr->watermark = 0;
@@ -675,13 +675,13 @@ void perf_evsel__config(struct perf_evsel *evsel,
}
if (opts->sample_weight)
- attr->sample_type |= PERF_SAMPLE_WEIGHT;
+ perf_evsel__set_sample_bit(evsel, WEIGHT);
attr->mmap = track;
attr->comm = track;
if (opts->sample_transaction)
- attr->sample_type |= PERF_SAMPLE_TRANSACTION;
+ perf_evsel__set_sample_bit(evsel, TRANSACTION);
/*
* XXX see the function comment above
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Add missing data.h into LIB_H headers
Commit-ID: 6e6dc401d528e3b64626de82322fa237f1c1e576 Gitweb: http://git.kernel.org/tip/6e6dc401d528e3b64626de82322fa237f1c1e576 Author: Jiri Olsa AuthorDate: Sat, 26 Oct 2013 20:53:14 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 4 Nov 2013 10:48:04 -0300 perf tools: Add missing data.h into LIB_H headers Adding missing data.h into LIB_H headers so the build could keep up with its changes. Reported-by: Adrian Hunter Cc: Adrian Hunter Cc: Andi Kleen Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20131026185314.ga14...@krava.brq.redhat.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 8a9ca38..bc7cfa1 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -295,6 +295,7 @@ LIB_H += ui/helpline.h LIB_H += ui/progress.h LIB_H += ui/util.h LIB_H += ui/ui.h +LIB_H += util/data.h LIB_OBJS += $(OUTPUT)util/abspath.o LIB_OBJS += $(OUTPUT)util/alias.o -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf report: Use parse_options_usage() for -s option failure
Commit-ID: 91aba0a62e24ff7a567e13e1d88deab711df6f0f
Gitweb: http://git.kernel.org/tip/91aba0a62e24ff7a567e13e1d88deab711df6f0f
Author: Namhyung Kim
AuthorDate: Fri, 1 Nov 2013 16:33:13 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:55:17 -0300
perf report: Use parse_options_usage() for -s option failure
The -s (--sort) option was processed after normal option parsing so that
it cannot call the parse_options_usage() automatically. Currently it
calls usage_with_options() which shows entire help messages for event
option. Fix it by showing just -s options.
$ perf report -s help
Error: Unknown --sort key: `help'
usage: perf report []
-s, --sort
sort by key(s): pid, comm, dso, symbol, ...
Signed-off-by: Namhyung Kim
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-4-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4df3161..25f83d5 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -947,8 +947,10 @@ repeat:
sort_order =
"local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked";
}
- if (setup_sorting() < 0)
- usage_with_options(report_usage, options);
+ if (setup_sorting() < 0) {
+ parse_options_usage(report_usage, options, "s", 1);
+ goto error;
+ }
if (parent_pattern != default_parent_pattern) {
if (sort_dimension__add("parent") < 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib traceevent: Add support for extracting trace_clock in report
Commit-ID: 1b372ca52a02cc97520c13d79bdfb0a7ff81b772
Gitweb: http://git.kernel.org/tip/1b372ca52a02cc97520c13d79bdfb0a7ff81b772
Author: Yoshihiro YUNOMAE
AuthorDate: Fri, 1 Nov 2013 17:53:53 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 14:33:12 -0300
tools lib traceevent: Add support for extracting trace_clock in report
If trace-cmd extracts trace_clock, trace-cmd reads trace_clock data from
the trace.dat and switches outputting format of timestamp for each
trace_clock.
Signed-off-by: Yoshihiro YUNOMAE
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20130424231305.14877.86147.stgit@yunodevel
Signed-off-by: Steven Rostedt
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 50 +-
tools/lib/traceevent/event-parse.h | 6 -
2 files changed, 44 insertions(+), 12 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index d1c2a6a..deedff9 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -305,6 +305,11 @@ int pevent_register_comm(struct pevent *pevent, const char
*comm, int pid)
return 0;
}
+void pevent_register_trace_clock(struct pevent *pevent, char *trace_clock)
+{
+ pevent->trace_clock = trace_clock;
+}
+
struct func_map {
unsigned long long addr;
char*func;
@@ -4443,8 +4448,21 @@ void pevent_event_info(struct trace_seq *s, struct
event_format *event,
trace_seq_terminate(s);
}
+static bool is_timestamp_in_us(char *trace_clock, bool use_trace_clock)
+{
+ if (!use_trace_clock)
+ return true;
+
+ if (!strcmp(trace_clock, "local") || !strcmp(trace_clock, "global")
+ || !strcmp(trace_clock, "uptime") || !strcmp(trace_clock, "perf"))
+ return true;
+
+ /* trace_clock is setting in tsc or counter mode */
+ return false;
+}
+
void pevent_print_event(struct pevent *pevent, struct trace_seq *s,
- struct pevent_record *record)
+ struct pevent_record *record, bool use_trace_clock)
{
static const char *spaces = ""; /* 20 spaces */
struct event_format *event;
@@ -4457,9 +4475,14 @@ void pevent_print_event(struct pevent *pevent, struct
trace_seq *s,
int pid;
int len;
int p;
+ bool use_usec_format;
- secs = record->ts / NSECS_PER_SEC;
- nsecs = record->ts - secs * NSECS_PER_SEC;
+ use_usec_format = is_timestamp_in_us(pevent->trace_clock,
+ use_trace_clock);
+ if (use_usec_format) {
+ secs = record->ts / NSECS_PER_SEC;
+ nsecs = record->ts - secs * NSECS_PER_SEC;
+ }
if (record->size < 0) {
do_warning("ug! negative record size %d", record->size);
@@ -4484,15 +4507,20 @@ void pevent_print_event(struct pevent *pevent, struct
trace_seq *s,
} else
trace_seq_printf(s, "%16s-%-5d [%03d]", comm, pid, record->cpu);
- if (pevent->flags & PEVENT_NSEC_OUTPUT) {
- usecs = nsecs;
- p = 9;
- } else {
- usecs = (nsecs + 500) / NSECS_PER_USEC;
- p = 6;
- }
+ if (use_usec_format) {
+ if (pevent->flags & PEVENT_NSEC_OUTPUT) {
+ usecs = nsecs;
+ p = 9;
+ } else {
+ usecs = (nsecs + 500) / NSECS_PER_USEC;
+ p = 6;
+ }
- trace_seq_printf(s, " %5lu.%0*lu: %s: ", secs, p, usecs, event->name);
+ trace_seq_printf(s, " %5lu.%0*lu: %s: ",
+ secs, p, usecs, event->name);
+ } else
+ trace_seq_printf(s, " %12llu: %s: ",
+ record->ts, event->name);
/* Space out the event names evenly. */
len = strlen(event->name);
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index c37b202..7503edf 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -20,6 +20,7 @@
#ifndef _PARSE_EVENTS_H
#define _PARSE_EVENTS_H
+#include
#include
#include
@@ -450,6 +451,8 @@ struct pevent {
/* cache */
struct event_format *last_event;
+
+ char *trace_clock;
};
static inline void pevent_set_flag(struct pevent *pevent, int flag)
@@ -527,6 +530,7 @@ enum trace_flag_type {
};
int pevent_register_comm(struct pevent *pevent, const char *comm, int pid);
+void pevent_register_trace_clock(struct pevent *pevent, char *trace_clock);
int pevent_register_function(struct pevent *pevent, char *name,
unsigned long long addr, char
[tip:perf/core] perf script: Set up output options for in-stream attributes
Commit-ID: 7ea95727af571d592c9d6aa7627690d44b114a2d
Gitweb: http://git.kernel.org/tip/7ea95727af571d592c9d6aa7627690d44b114a2d
Author: Adrian Hunter
AuthorDate: Fri, 1 Nov 2013 15:51:30 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:19:26 -0300
perf script: Set up output options for in-stream attributes
Attributes (struct perf_event_attr) are recorded separately in the
perf.data file. perf script uses them to set up output options.
However attributes can also be in the event stream, for example when the
input is a pipe (i.e. live mode). This patch makes perf script process
in-stream attributes in the same way as on-file attributes.
Here is an example:
Before this patch:
$ perf record uname | perf script
Linux
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.015 MB (null) (~655 samples) ]
:4220 4220 [-01] 2933367.838906: cycles:
:4220 4220 [-01] 2933367.838910: cycles:
:4220 4220 [-01] 2933367.838912: cycles:
:4220 4220 [-01] 2933367.838914: cycles:
:4220 4220 [-01] 2933367.838916: cycles:
:4220 4220 [-01] 2933367.838918: cycles:
uname 4220 [-01] 2933367.838938: cycles:
uname 4220 [-01] 2933367.839207: cycles:
After this patch:
$ perf record uname | perf script
Linux
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.015 MB (null) (~655 samples) ]
:4582 4582 2933425.707724: cycles: 81043ffa
native_write_msr_safe ([kernel.kallsyms])
:4582 4582 2933425.707728: cycles: 81043ffa
native_write_msr_safe ([kernel.kallsyms])
:4582 4582 2933425.707730: cycles: 81043ffa
native_write_msr_safe ([kernel.kallsyms])
:4582 4582 2933425.707732: cycles: 81043ffa
native_write_msr_safe ([kernel.kallsyms])
:4582 4582 2933425.707734: cycles: 81043ffa
native_write_msr_safe ([kernel.kallsyms])
:4582 4582 2933425.707736: cycles: 81309a24 memcpy
([kernel.kallsyms])
uname 4582 2933425.707760: cycles: 8109c1c7
enqueue_task_fair ([kernel.kallsyms])
uname 4582 2933425.707978: cycles: 81308457 clear_page_c
([kernel.kallsyms])
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-3-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-script.c | 64 +
1 file changed, 48 insertions(+), 16 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index b866cc8..baf1798 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -229,6 +229,24 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
return 0;
}
+static void set_print_ip_opts(struct perf_event_attr *attr)
+{
+ unsigned int type = attr->type;
+
+ output[type].print_ip_opts = 0;
+ if (PRINT_FIELD(IP))
+ output[type].print_ip_opts |= PRINT_IP_OPT_IP;
+
+ if (PRINT_FIELD(SYM))
+ output[type].print_ip_opts |= PRINT_IP_OPT_SYM;
+
+ if (PRINT_FIELD(DSO))
+ output[type].print_ip_opts |= PRINT_IP_OPT_DSO;
+
+ if (PRINT_FIELD(SYMOFFSET))
+ output[type].print_ip_opts |= PRINT_IP_OPT_SYMOFFSET;
+}
+
/*
* verify all user requested events exist and the samples
* have the expected data
@@ -237,7 +255,6 @@ static int perf_session__check_output_opt(struct
perf_session *session)
{
int j;
struct perf_evsel *evsel;
- struct perf_event_attr *attr;
for (j = 0; j < PERF_TYPE_MAX; ++j) {
evsel = perf_session__find_first_evtype(session, j);
@@ -260,20 +277,7 @@ static int perf_session__check_output_opt(struct
perf_session *session)
if (evsel == NULL)
continue;
- attr = >attr;
-
- output[j].print_ip_opts = 0;
- if (PRINT_FIELD(IP))
- output[j].print_ip_opts |= PRINT_IP_OPT_IP;
-
- if (PRINT_FIELD(SYM))
- output[j].print_ip_opts |= PRINT_IP_OPT_SYM;
-
- if (PRINT_FIELD(DSO))
- output[j].print_ip_opts |= PRINT_IP_OPT_DSO;
-
- if (PRINT_FIELD(SYMOFFSET))
- output[j].print_ip_opts |= PRINT_IP_OPT_SYMOFFSET;
+ set_print_ip_opts(>attr);
}
return 0;
@@ -547,6 +551,34 @@ struct perf_script {
struct perf_session *session;
};
+static int process_attr(struct perf_tool *tool, union perf_event *event,
+ struct perf_evlist **pevlist)
+{
+ struct perf_script *scr = container_of(tool, struct perf_script, tool);
+ struct perf_evlist
[tip:perf/core] perf tools: Fix 32-bit cross build
Commit-ID: 28e962b9d79f496f214d7fc8ffd1a3f2a67e9090 Gitweb: http://git.kernel.org/tip/28e962b9d79f496f214d7fc8ffd1a3f2a67e9090 Author: Adrian Hunter AuthorDate: Fri, 1 Nov 2013 15:51:31 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 4 Nov 2013 12:20:45 -0300 perf tools: Fix 32-bit cross build Setting EXTRA_CFLAGS=-m32 did not work because it was not passed around. Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1383313899-15987-4-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 2 +- tools/perf/config/Makefile| 4 ++-- tools/perf/config/feature-checks/Makefile | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index cb52bdb..5b86390 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -711,7 +711,7 @@ $(LIB_FILE): $(LIB_OBJS) TE_SOURCES = $(wildcard $(TRACE_EVENT_DIR)*.[ch]) $(LIBTRACEEVENT): $(TE_SOURCES) - $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) libtraceevent.a + $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) CFLAGS="-g -Wall $(EXTRA_CFLAGS)" libtraceevent.a $(LIBTRACEEVENT)-clean: $(call QUIET_CLEAN, libtraceevent) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 543aa95..2f1d7d7 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -96,7 +96,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) @@ -173,7 +173,7 @@ ifeq ($(feature-all), 1) # $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat))) else - $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1) + $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1) $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat))) endif diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index 452b67c..353c00c 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -31,7 +31,7 @@ CC := $(CC) -MD all: $(FILES) -BUILD = $(CC) $(LDFLAGS) -o $(OUTPUT)$@ $@.c +BUILD = $(CC) $(CFLAGS) $(LDFLAGS) -o $(OUTPUT)$@ $@.c ### -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Get current comm instead of last one
Commit-ID: 4dfced359fbc719a35527416f1b4b3999647f68b
Gitweb: http://git.kernel.org/tip/4dfced359fbc719a35527416f1b4b3999647f68b
Author: Namhyung Kim
AuthorDate: Fri, 13 Sep 2013 16:28:57 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:16:39 -0300
perf tools: Get current comm instead of last one
At insert time, a hist entry should reference comm at the time otherwise
it'll get the last comm anyway.
Signed-off-by: Namhyung Kim
Acked-by: Frederic Weisbecker
Tested-by: Jiri Olsa
Cc: Frederic Weisbecker
Link: http://lkml.kernel.org/n/tip-n6pykiiymtgmcjs834go2...@git.kernel.org
[ Fixed up const pointer issues ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/comm.c | 15 +++
tools/perf/util/comm.h | 1 +
tools/perf/util/hist.c | 3 +++
tools/perf/util/sort.c | 14 +-
tools/perf/util/sort.h | 1 +
tools/perf/util/thread.c | 6 +++---
tools/perf/util/thread.h | 2 ++
7 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/comm.c b/tools/perf/util/comm.c
index 8b3ac9f..ee0df0e 100644
--- a/tools/perf/util/comm.c
+++ b/tools/perf/util/comm.c
@@ -94,6 +94,21 @@ struct comm *comm__new(const char *str, u64 timestamp)
return comm;
}
+void comm__override(struct comm *comm, const char *str, u64 timestamp)
+{
+ struct comm_str *old = comm->comm_str;
+
+ comm->comm_str = comm_str__findnew(str, _str_root);
+ if (!comm->comm_str) {
+ comm->comm_str = old;
+ return;
+ }
+
+ comm->start = timestamp;
+ comm_str__get(comm->comm_str);
+ comm_str__put(old);
+}
+
void comm__free(struct comm *comm)
{
comm_str__put(comm->comm_str);
diff --git a/tools/perf/util/comm.h b/tools/perf/util/comm.h
index f62d215..7a86e56 100644
--- a/tools/perf/util/comm.h
+++ b/tools/perf/util/comm.h
@@ -16,5 +16,6 @@ struct comm {
void comm__free(struct comm *comm);
struct comm *comm__new(const char *str, u64 timestamp);
const char *comm__str(const struct comm *comm);
+void comm__override(struct comm *comm, const char *str, u64 timestamp);
#endif /* __PERF_COMM_H */
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 7e80253..30793f9 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -416,6 +416,7 @@ struct hist_entry *__hists__add_mem_entry(struct hists
*hists,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = thread__comm(al->thread),
.ms = {
.map= al->map,
.sym= al->sym,
@@ -446,6 +447,7 @@ struct hist_entry *__hists__add_branch_entry(struct hists
*hists,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = thread__comm(al->thread),
.ms = {
.map= bi->to.map,
.sym= bi->to.sym,
@@ -475,6 +477,7 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = thread__comm(al->thread),
.ms = {
.map= al->map,
.sym= al->sym,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index bf91d0e..3c1b75c 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1,5 +1,6 @@
#include "sort.h"
#include "hist.h"
+#include "comm.h"
#include "symbol.h"
regex_tparent_regex;
@@ -81,25 +82,20 @@ static int64_t
sort__comm_cmp(struct hist_entry *left, struct hist_entry *right)
{
/* Compare the addr that should be unique among comm */
- return thread__comm_str(right->thread) - thread__comm_str(left->thread);
+ return comm__str(right->comm) - comm__str(left->comm);
}
static int64_t
sort__comm_collapse(struct hist_entry *left, struct hist_entry *right)
{
- const char *comm_l = thread__comm_str(left->thread);
- const char *comm_r = thread__comm_str(right->thread);
-
- if (!comm_l || !comm_r)
- return cmp_null(comm_l, comm_r);
-
- return strcmp(comm_l, comm_r);
+ /* Compare the addr that should be unique among comm */
+ return comm__str(right->comm) - comm__str(left->comm);
}
static int hist_entry__comm_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
- return repsep_snprintf(bf, size, "%*s", width,
thread__comm_str(he->thread));
+ return repsep_snprintf(bf, size, "%*s", width, comm__str(he->comm));
}
struct sort_entry sort_comm = {
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index bf43336..f4e16f3 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -84,6 +84,7 @@ struct hist_entry {
struct he_stat stat;
struct map_symbol ms;
struct thread
[tip:perf/core] perf tools: Fix libunwind build and feature detection for 32-bit build
Commit-ID: 8a0c4c2843d3b72e23c3c12079b8d5c3ae99f3e3 Gitweb: http://git.kernel.org/tip/8a0c4c2843d3b72e23c3c12079b8d5c3ae99f3e3 Author: Adrian Hunter AuthorDate: Fri, 1 Nov 2013 15:51:32 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 4 Nov 2013 12:21:18 -0300 perf tools: Fix libunwind build and feature detection for 32-bit build Use -lunwind-x86 instead of -lunwind-x86_64 for 32-bit build. Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1383313899-15987-5-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/config/Makefile| 6 -- tools/perf/config/feature-checks/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 2f1d7d7..ffb5f55 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -25,9 +25,11 @@ ifeq ($(ARCH),x86_64) RAW_ARCH := x86_64 CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT ARCH_INCLUDE = ../../arch/x86/lib/memcpy_64.S ../../arch/x86/lib/memset_64.S +LIBUNWIND_LIBS = -lunwind -lunwind-x86_64 + else +LIBUNWIND_LIBS = -lunwind -lunwind-x86 endif NO_PERF_REGS := 0 - LIBUNWIND_LIBS = -lunwind -lunwind-x86_64 endif ifeq ($(NO_PERF_REGS),0) @@ -96,7 +98,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) LIBUNWIND_LIBS="$(LIBUNWIND_LIBS)" -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index 353c00c..d37d58d 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -36,7 +36,7 @@ BUILD = $(CC) $(CFLAGS) $(LDFLAGS) -o $(OUTPUT)$@ $@.c ### test-all: - $(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lunwind -lunwind-x86_64 -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl + $(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma $(LIBUNWIND_LIBS) -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl test-hello: $(BUILD) @@ -72,7 +72,7 @@ test-libnuma: $(BUILD) -lnuma test-libunwind: - $(BUILD) -lunwind -lunwind-x86_64 -lelf + $(BUILD) $(LIBUNWIND_LIBS) -lelf test-libaudit: $(BUILD) -laudit -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf evsel: Add a debug print if perf_event_open fails
Commit-ID: f852fd621ca19f557f2e3d05900366be7c7afb83
Gitweb: http://git.kernel.org/tip/f852fd621ca19f557f2e3d05900366be7c7afb83
Author: Adrian Hunter
AuthorDate: Fri, 1 Nov 2013 15:51:29 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:18:17 -0300
perf evsel: Add a debug print if perf_event_open fails
There is a debug print (at verbose level 2) for each call to
perf_event_open. Add another debug print if the call fails, and print
the error number.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-2-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 3a334f0..f0e65de 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1051,6 +1051,8 @@ retry_open:
group_fd,
flags);
if (FD(evsel, cpu, thread) < 0) {
err = -errno;
+ pr_debug2("perf_event_open failed, error %d\n",
+ err);
goto try_fallback;
}
set_rlimit = NO_CHANGE;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Compare hists comm by addresses
Commit-ID: fedd63d3cdc9004df43b02df5c874b8957992fe8
Gitweb: http://git.kernel.org/tip/fedd63d3cdc9004df43b02df5c874b8957992fe8
Author: Frederic Weisbecker
AuthorDate: Wed, 11 Sep 2013 17:18:09 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 12:14:59 -0300
perf tools: Compare hists comm by addresses
Now that comm strings are allocated only once and refcounted to be shared
among threads, these can now be safely compared by addresses. This
should remove most hists collapses on post processing.
Signed-off-by: Frederic Weisbecker
Tested-by: Jiri Olsa
Cc: Jiri Olsa
Cc: David Ahern
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1381468543-25334-8-git-send-email-namhy...@kernel.org
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 835e8bd..bf91d0e 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -80,7 +80,8 @@ struct sort_entry sort_thread = {
static int64_t
sort__comm_cmp(struct hist_entry *left, struct hist_entry *right)
{
- return right->thread->tid - left->thread->tid;
+ /* Compare the addr that should be unique among comm */
+ return thread__comm_str(right->thread) - thread__comm_str(left->thread);
}
static int64_t
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf probe: Fix typo
Commit-ID: 9ef0438a957937bf0edc26d58bce891034ff9e30
Gitweb: http://git.kernel.org/tip/9ef0438a957937bf0edc26d58bce891034ff9e30
Author: Arnaldo Carvalho de Melo
AuthorDate: Thu, 24 Oct 2013 17:36:31 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 4 Nov 2013 10:48:02 -0300
perf probe: Fix typo
s/tyep/type/g.
Cc: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Mike Galbraith
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-cznw5tnruonyoisxu8be1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/probe-finder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index e41b094..2200dad 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -583,7 +583,7 @@ static int convert_variable_fields(Dwarf_Die *vr_die, const
char *varname,
}
if (die_find_member(, field->name, die_mem) == NULL) {
- pr_warning("%s(tyep:%s) has no member %s.\n", varname,
+ pr_warning("%s(type:%s) has no member %s.\n", varname,
dwarf_diename(), field->name);
return -EINVAL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
Am 04.11.2013 20:49, schrieb Geert Uytterhoeven: On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler wrote: 3.14 3.141 3.1415 3.14159 3.141592 3.1415926 (...) 4.0 Since when does \pi converge to 4.0? The attention span of most people is usually limited, so they won't follow very long. Besides that people have a problem with very long numbers. So an end is needed. But extending that scheme to the stable series might be interesting too, producing stable kernels 3.14.1 3.14.15 ... and 3.141.5 3.141.59 ... That would lead to an interesting looking kernel.org page before switching to 4.0. And I assume it would make many people very happy when the kernel finally switches to 4.0. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] bcache changes for 3.13
On 11/04/2013 01:16 PM, Kent Overstreet wrote: > On Mon, Nov 04, 2013 at 01:12:17PM -0700, Jens Axboe wrote: >> On 11/04/2013 01:07 PM, Kent Overstreet wrote: >>> Hey Jens, sorry for being late with this - anyways, it's roughly the same >>> set of >>> patches you had queued up before plus a few minor fixes, but it's been >>> rebased >>> onto your for-3.13/core branch. >> >> Merge window is a little later this time, and since it was already in >> for the previous release, we can make it happen. >> >> But can you please base it on for-3.13/drivers however? That's where I'd >> like to pull in the driver bits, and if I pull this one, then things get >> even more tangled since for-3.13/core is holding the blk-mq changes too. > > I'd like to do the merge with immutable biovecs myself though - there's some > tricky bits in there. How will that work? OK, in that case, yeah it might be easier to just pull it in wholesale. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/29] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit 46d525eae2a076adfde92dca1db12d9a3b8ad8bb: > > perf test: Update command line callchain attribute tests (2013-11-01 > 10:42:57 -0300) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > tags/perf-urgent-for-mingo I guess this wanted to be perf-core-for-mingo? Pulled those bits, thanks Arnaldo! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] bcache changes for 3.13
On Mon, Nov 04, 2013 at 01:12:17PM -0700, Jens Axboe wrote: > On 11/04/2013 01:07 PM, Kent Overstreet wrote: > > Hey Jens, sorry for being late with this - anyways, it's roughly the same > > set of > > patches you had queued up before plus a few minor fixes, but it's been > > rebased > > onto your for-3.13/core branch. > > Merge window is a little later this time, and since it was already in > for the previous release, we can make it happen. > > But can you please base it on for-3.13/drivers however? That's where I'd > like to pull in the driver bits, and if I pull this one, then things get > even more tangled since for-3.13/core is holding the blk-mq changes too. I'd like to do the merge with immutable biovecs myself though - there's some tricky bits in there. How will that work? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] KVM: IOMMU: hva align mapping page size
On Mon, Nov 04, 2013 at 09:08:12AM -0700, Greg Edwards wrote: > When determining the page size we could use to map with the IOMMU, the > page size should also be aligned with the hva, not just the gfn. The > gfn may not reflect the real alignment within the hugetlbfs file. > > Signed-off-by: Greg Edwards > Cc: sta...@vger.kernel.org > --- > virt/kvm/iommu.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/virt/kvm/iommu.c b/virt/kvm/iommu.c > index 72a130b..c329c8f 100644 > --- a/virt/kvm/iommu.c > +++ b/virt/kvm/iommu.c > @@ -103,6 +103,10 @@ int kvm_iommu_map_pages(struct kvm *kvm, struct > kvm_memory_slot *slot) > while ((gfn << PAGE_SHIFT) & (page_size - 1)) > page_size >>= 1; > > + /* Make sure hva is aligned to the page size we want to map */ > + while (__gfn_to_hva_memslot(slot, gfn) & (page_size - 1)) > + page_size >>= 1; > + > /* >* Pin all pages we are about to map in memory. This is >* important because we unmap and unpin in 4kb steps later. > -- > 1.8.3.2 Reviewed-by: Marcelo Tosatti -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] bcache changes for 3.13
On 11/04/2013 01:07 PM, Kent Overstreet wrote: > Hey Jens, sorry for being late with this - anyways, it's roughly the same set > of > patches you had queued up before plus a few minor fixes, but it's been rebased > onto your for-3.13/core branch. Merge window is a little later this time, and since it was already in for the previous release, we can make it happen. But can you please base it on for-3.13/drivers however? That's where I'd like to pull in the driver bits, and if I pull this one, then things get even more tangled since for-3.13/core is holding the blk-mq changes too. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 02/13] driver: net: remove unnecessary skb NULL check before calling dev_kfree_skb_irq
From: Govindarajulu Varadarajan
Date: Sat, 2 Nov 2013 19:17:43 +0530
> @@ -1030,10 +1030,8 @@ static void ni65_xmit_intr(struct net_device *dev,int
> csr0)
> }
>
> #ifdef XMT_VIA_SKB
> - if(p->tmd_skb[p->tmdlast]) {
> - dev_kfree_skb_irq(p->tmd_skb[p->tmdlast]);
> - p->tmd_skb[p->tmdlast] = NULL;
> - }
> + dev_kfree_skb_irq(p->tmd_skb[p->tmdlast]);
> + p->tmd_skb[p->tmdlast] = NULL;
> #endif
I absolutely disagree with this kind of change.
There is a non-trivial cost for NULL'ing out that array entry
unconditionally. It's a dirtied cache line and this is in the
fast path of TX SKB reclaim of this driver.
You've made several changes of this kind.
And it sort-of shows that the places that do check for NULL,
are getting something in return for that test, namely avoidance
of an unnecessary cpu store in the fast path of the driver.
I'm throwing away this series, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for-next] dm: fix missing bi_remaining accounting
On Mon, Nov 04, 2013 at 10:06:00AM -0500, Mikulas Patocka wrote: > > > On Fri, 1 Nov 2013, Jens Axboe wrote: > > > On 11/01/2013 07:59 AM, Mike Snitzer wrote: > > > Add the missing bi_remaining increment, required by the block layer's > > > new bio-chaining code, to both the verity and old snapshot DM targets. > > > > > > Otherwise users will hit the bi_remaining <= 0 BUG_ON in bio_endio(). > > > > Thanks Mike, added to the mix. > > > > -- > > Jens Axboe > > Hi > > This improves a little bit on the previous patch, by replacing costly > atomic_inc with cheap atomic_set. IMO, this is a bad idea; the behaviour with this patch does _not_ match the naming of bio_endio_nodec(), and the performance difference should be well in the noise anyways because we're touching a cacheline we already have in cache and won't be contended. The fact that it's currently safe is accidental, I could see this easily tripping people up and being a pain in the ass to debug in the future. > > > From: Mikulas Patocka > > dm: change atomic_inc to atomic_set(1) > > There are places in dm where we save bi_endio and bi_private, set them to > target's routine, submit the bio, from the target's bi_endio routine we > restore bi_endio and bi_private and end the bio with bi_endio. > > This causes underflow of bi_remaining, so we must restore bi_remaining > before ending the bio from the target bi_endio routine. > > The code uses atomic_inc for restoration of bi_remaining. This patch > changes it to atomic_set(1) to avoid an interlocked instruction. In the > target's bi_endio routine we are sure that bi_remaining is zero > (otherwise, the bi_endio routine wouldn't be called) and there are no > concurrent users of the bio, so we can replace atomic_inc with > atomic_set(1). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Allow NR_CPUS=1024
* H. Peter Anvin wrote: > 8192 maybe? Yeah, that makes more sense I guess. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] bcache changes for 3.13
Hey Jens, sorry for being late with this - anyways, it's roughly the same set of patches you had queued up before plus a few minor fixes, but it's been rebased onto your for-3.13/core branch. The following changes since commit febca1baea1cfe2d7a0271385d89b03d5fb34f94: block: setup bi_vcnt on clones (2013-10-31 13:32:42 -0600) are available in the git repository at: git://evilpiepirate.org/~kent/linux-bcache.git bcache-for-3.13 for you to fetch changes up to 0bb953dba5d295b03bb035bfc2d28ed4155df377: bcache: defensively handle format strings (2013-11-01 18:03:20 -0700) Kees Cook (1): bcache: defensively handle format strings Kent Overstreet (53): bcache: Fixed incorrect order of arguments to bio_alloc_bioset() bcache: Convert bch_data_verify() to immutable biovecs bcache: Fix a journalling performance bug bcache: Fix a lockdep splat bcache: Use blkdev_issue_discard() bcache: Add on error panic/unregister setting bcache: Stripe size isn't necessarily a power of two bcache: Remove unnecessary check in should_split() bcache: Explicitly track btree node's parent bcache: Add btree_insert_node() bcache: Insert multiple keys at a time bcache: Convert btree_insert_check_key() to btree_insert_node() bcache: Add explicit keylist arg to btree_insert() bcache: Clean up keylist code bcache: Refactor request_write() bcache: Refactor read request code a bit bcache: Refactor journalling flow control bcache: Move keylist out of btree_op bcache: Convert try_wait to wait_queue_head_t bcache: Convert bucket_wait to wait_queue_head_t bcache: Convert gc to a kthread bcache: Convert writeback to a kthread bcache: Add btree_map() functions bcache: Move some stuff to btree.c bcache: Convert bch_btree_read_async() to bch_btree_map_keys() bcache: Clean up cache_lookup_fn bcache: Prune struct btree_op bcache: Kill op->cl bcache: Drop some closure stuff bcache: Kill op->replace bcache: Don't use op->insert_collision bcache: Convert bch_btree_insert() to bch_btree_map_leaf_nodes() bcache: Break up struct search bcache: Move sector allocator to alloc.c bcache: Pull on disk data structures out into a separate header bcache: Fix bch_ptr_bad() bcache: Debug code improvements bcache: Don't bother with bucket refcount for btree node allocations bcache: bch_(btree|extent)_ptr_invalid() bcache: PRECEDING_KEY() bcache: Add btree_node_write_sync() bcache: Add make_btree_freeing_key() bcache: Incremental gc bcache: Avoid deadlocking in garbage collection bcache: Kill bch_next_recurse_key() bcache: Kill sequential_merge option bcache: Move spinlock into struct time_stats bcache: Have btree_split() insert into parent directly bcache: Better full stripe scanning bcache: Fix sysfs splat on shutdown with flash only devs bcache: Use ida for bcache block dev minor bcache: Delete some slower inline asm bcache: Bypass torture test drivers/md/bcache/Kconfig | 11 +- drivers/md/bcache/alloc.c | 383 +++- drivers/md/bcache/bcache.h| 327 +- drivers/md/bcache/bset.c | 289 - drivers/md/bcache/bset.h | 93 +-- drivers/md/bcache/btree.c | 1386 ++--- drivers/md/bcache/btree.h | 195 ++ drivers/md/bcache/closure.c | 103 +-- drivers/md/bcache/closure.h | 183 +- drivers/md/bcache/debug.c | 202 +++--- drivers/md/bcache/debug.h | 50 +- drivers/md/bcache/journal.c | 293 + drivers/md/bcache/journal.h | 52 +- drivers/md/bcache/movinggc.c | 85 ++- drivers/md/bcache/request.c | 1106 drivers/md/bcache/request.h | 42 +- drivers/md/bcache/stats.c | 26 +- drivers/md/bcache/stats.h | 13 +- drivers/md/bcache/super.c | 190 +++--- drivers/md/bcache/sysfs.c | 42 +- drivers/md/bcache/trace.c |1 - drivers/md/bcache/util.c | 12 +- drivers/md/bcache/util.h | 15 +- drivers/md/bcache/writeback.c | 455 +++--- drivers/md/bcache/writeback.h | 46 +- include/trace/events/bcache.h | 47 +- include/uapi/linux/bcache.h | 373 +++ 27 files changed, 3006 insertions(+), 3014 deletions(-) create mode 100644 include/uapi/linux/bcache.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Sun, Nov 3, 2013 at 4:10 PM, Linus Torvalds wrote: > The reason I mention it is because I've been mulling over something > Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked > at the Q session whether we could do a release with just stability > and bug-fixes, and I pooh-poohed it because I didn't see most of us > having the attention span required for that > (cough*cough*moronic*woodland creature*cough*cough). > > So I may be pessimistic, but I'd expect many developers would go > "Let's hunt bugs.. Wait. Oooh, shiny" and go off doing some new > feature after all instead. Or just take that release off. > > But I do wonder.. Maybe it would be possible, and I'm just unfairly > projecting my own inner squirrel onto other kernel developers. If we > have enough heads-up that people *know* that for one release (and > companies/managers know that too) the only patches that get accepted > are the kind that fix bugs, maybe people really would have sufficient > attention span that it could work. > > And the reason I mention "4.0" is that it would be a lovely time to do > that. Roughly a years heads-up that "ok, after 3.19 (or whatever), > we're doing a release with *just* fixes, and then that becomes 4.0". > > Comments? Ingo has some very good points. I think this might be worth doing in some form or other, but if it's worth a full release cycle is less certain to me: Essentially we already do this for every release, where the last couple of weeks are strictly bugfixes only. While it's not what you're proposing, the end result sounds to me more like a "forced" extension of the -rc cycle by several weeks to let more of those fixes come in. If you're doing a 3.20/4.0 that is bugfixes only, then why release 3.19 at all? If the only difference between the two is said fixes, we'd be better off just holding on until the latter is released. Which again comes back to in practice extending the release by several more weeks of late -rcs. The only benefit I can think of to make a 3.19 release is to pick up more users, if some of them avoid -rcs but do use full releases shortly after they are tagged. I don't know how common that is though. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: mm, numa: test segfaults, only when NUMA balancing is on
On Mon, Nov 04, 2013 at 02:58:28PM +, Mel Gorman wrote: > On Wed, Oct 16, 2013 at 10:54:29AM -0500, Alex Thorlton wrote: > > Hi guys, > > > > I ran into a bug a week or so ago, that I believe has something to do > > with NUMA balancing, but I'm having a tough time tracking down exactly > > what is causing it. When running with the following configuration > > options set: > > > > Can you test with patches > cd65718712469ad844467250e8fad20a5838baae..0255d491848032f6c601b6410c3b8ebded3a37b1 > applied? They fix some known memory corruption problems, were merged for > 3.12 (so alternatively just test 3.12) and have been tagged for -stable. I just finished testing with 3.12, and I'm still seeing the same issue. This is actually a bit strange to me, because, when I tested with 3.12-rc5 a while back, everything seemed to be ok (see previoues e-mail in this thread, to Bob Liu). I guess, embarrasingly enough, I must have been playing with a screwed up config that day, and managed to somehow avoid the problem... Either way, it appears that we still have a problem here. I'll poke around a bit more on this in the next few days and see if I can come up with any more information. In the meantime, let me know if you have any other suggestions. Thanks, - Alex > > Thanks. > > -- > Mel Gorman > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Mon, Nov 4, 2013 at 8:08 PM, Josh Boyer wrote:
>>> So I may be pessimistic, but I'd expect many developers would go "Let's
>>> hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after
>>> all instead. Or just take that release off.
>>>
>>> But I do wonder.. Maybe it would be possible, and I'm just unfairly
>>> projecting my own inner squirrel onto other kernel developers. If we
>>> have enough heads-up that people *know* that for one release (and
>>> companies/managers know that too) the only patches that get accepted are
>>> the kind that fix bugs, maybe people really would have sufficient
>>> attention span that it could work.
>>>
>>> And the reason I mention "4.0" is that it would be a lovely time to do
>>> that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're
>>> doing a release with *just* fixes, and then that becomes 4.0".
>>>
>>> Comments?
>>
>> I think the biggest problem wouldn't even be the enforcement of
>> bugfixes-only during that 2.5 months period, or kernel developers
>> surviving such a long streak of boredom, but v3.19 would also probably be
>> a super-stressful release to maintainers, as everyone would try to cram
>> their feature in there. And if anything important misses that window then
>> it's a +5 months wait...
>
> I'd agree with that, but it wouldn't be limited to just the final
> non-bugfix release. It would be a year-long "shove as much as we can
> in" push, and I'd be fearful of doing any distro kernel based on any
> one of those releases. Clearly the subsystem maintainers would still
> be fighting the good fight, but I'm concerned they'd be overwhelmed
> and/or burnt out by the time 4.0 came around.
I'm afraid to avoid that, you have to do the bug-fixing release *now*,
without early warning...
Yes, it screws all short-term planning, but it relieves the stress from all
maintainters, and puts the stress/blame on a single person, of which we
all know he can handle it and say "no".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Mon, Nov 4, 2013 at 6:00 PM, Alexander Holler wrote:
> 3.14
> 3.141
> 3.1415
> 3.14159
> 3.141592
> 3.1415926
> (...)
> 4.0
Since when does \pi converge to 4.0?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] uprobes: introduce arch_uprobe->ixol
On 10/29, Oleg Nesterov wrote:
>
> David. Perhaps we can avoid the new hook altogether? What if we do
> the simple change below (it ignores powerpc) ?
>
> Then arm can add "unsigned long ixol[2]" into its arch_uprobe, and
> arch_uprobe_analyze_insn() can initialize this member correctly.
>
> What do you think?
Seriouly, how about the patch below?
In fact, given that you are going to reimplement set_swbp/orig_insn,
the new member is not strictly needed (afaics). But it looks more
clear this way, and we need s/MAX_UINSN_BYTES/sizeof()/ anyway.
Oleg.
---
Subject: [PATCH] uprobes: introduce arch_uprobe->ixol
Currently xol_get_insn_slot() assumes that we should simply copy
arch_uprobe->insn[] which is (ignoring arch_uprobe_analyze_insn)
just the copy of the original insn.
This is not true for arm which needs to create another insn to
execute it out-of-line.
So this patch simply adds the new member, ->ixol into the union.
This doesn't make any difference for x86 and powerpc, but arm
can divorce insn/ixol and initialize the correct xol insn in
arch_uprobe_analyze_insn().
Signed-off-by: Oleg Nesterov
---
arch/powerpc/include/asm/uprobes.h |1 +
arch/x86/include/asm/uprobes.h |5 -
kernel/events/uprobes.c|3 ++-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/uprobes.h
b/arch/powerpc/include/asm/uprobes.h
index 2301602..541fd6f 100644
--- a/arch/powerpc/include/asm/uprobes.h
+++ b/arch/powerpc/include/asm/uprobes.h
@@ -37,6 +37,7 @@ typedef ppc_opcode_t uprobe_opcode_t;
struct arch_uprobe {
union {
u8 insn[MAX_UINSN_BYTES];
+ u8 ixol[MAX_UINSN_BYTES];
u32 ainsn;
};
};
diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
index 6e51979..2a24180 100644
--- a/arch/x86/include/asm/uprobes.h
+++ b/arch/x86/include/asm/uprobes.h
@@ -35,7 +35,10 @@ typedef u8 uprobe_opcode_t;
struct arch_uprobe {
u16 fixups;
- u8 insn[MAX_UINSN_BYTES];
+ union {
+ u8 insn[MAX_UINSN_BYTES];
+ u8 ixol[MAX_UINSN_BYTES];
+ };
#ifdef CONFIG_X86_64
unsigned long rip_rela_target_address;
#endif
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ad8e1bd..6aef5ad 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1256,7 +1256,8 @@ static unsigned long xol_get_insn_slot(struct uprobe
*uprobe)
return 0;
/* Initialize the slot */
- copy_to_page(area->page, xol_vaddr, uprobe->arch.insn, MAX_UINSN_BYTES);
+ copy_to_page(area->page, xol_vaddr,
+ uprobe->arch.ixol, sizeof(uprobe->arch.ixol));
/*
* We probably need flush_icache_user_range() but it needs vma.
* This should work on supported architectures too.
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/6] hardirq: Make hardirq bits generic
Hi Thomas,
On Mon, 4 Nov 2013, Thomas Gleixner wrote:
> On Thu, 19 Sep 2013, Geert Uytterhoeven wrote:
> > However, the resulting kernel hangs (on ARAnyM) after starting userspace:
> >
> > | INIT: version 2.86 booting
> >
> > I'll have a deeper look when I have some more time...
>
> Any chance that you find some more time? :)
Sure!
But only if you look at "[m68k] IRQ: add handle_polled_irq() for timer
based soft interrupt" (http://www.spinics.net/lists/linux-m68k/msg05889.html)
first ;-)
Below is a patch with some fixups, on top of your two patches.
Unfortunately it still hangs somewhere after mounting the root filesystem.
Using this debug code for do_IRQ():
diff --git a/arch/m68k/kernel/irq.c b/arch/m68k/kernel/irq.c
index aaf7b15fad41..da9687803d98 100644
--- a/arch/m68k/kernel/irq.c
+++ b/arch/m68k/kernel/irq.c
@@ -22,11 +22,21 @@ asmlinkage int do_IRQ(int irq, struct pt_regs *regs)
struct pt_regs *oldregs = set_irq_regs(regs);
int nested = regs->sr & ~ALLOWINT;
+static int nesting;
+const char prefix[] = "";
+unsigned long flags;
+local_irq_save(flags);
+nesting++;
+printk("# %sirq %d nested %d\n", [16-2*nesting], irq, nested);
+local_irq_restore(flags);
irq_enter();
generic_handle_irq(irq);
irq_exit_nested(nested);
set_irq_regs(oldregs);
+local_irq_save(flags);
+nesting--;
+local_irq_restore(flags);
return nested;
}
I get output like
# irq 15 nested 0
# irq 15 nested 1024
irq 15 while irq 15 in progress??
# irq 15 nested 1024
# irq 15 nested 1024
# irq 15 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 4 nested 0
# irq 13 nested 1024
# irq 4 nested 0
# irq 13 nested 1024
# irq 4 nested 0
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 4 nested 0
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 13 nested 1024
# irq 4 nested 0
# irq 13 nested 1024
# irq 13 nested 1024
[...]
# irq 13 nested 1024
# irq 13 nested 1024
# irq 4 nested 0
# irq 13 nested 1024
# irq 4 nested 0
irq 4 while irq 4 in progress?
# irq 13 nested 1024
# irq 4 nested 0
# irq 13 nested 0
and then it stops printing anything.
With similar debug code on the old working do_IRQ(), I get
- slightly less deep nesting,
- do_IRQ() is never re-entered with the same irq number.
Also note that the value of "nested" doesn't match the indentation level,
which depends on my own bookkeeping using "nesting".
Anyone with an idea where it's going wrong?
Thanks!
>From 209b6ac37811297cd305821c5689dff75226af48 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven
Date: Sun, 22 Sep 2013 11:31:25 +0200
Subject: [PATCH] m68k/hardirq: Make hardirq bits generic fixups
- tstl instead of cmpl #0 (from Andreas)
- arch/m68k/kernel/built-in.o: In function `bad_inthandler': (.text+0x2a6):
undefined reference to `ret_from_last_interrupt'
- Handle nesting in bad_inthandler() and handle_badint(),
- As do_IRQ() now returns int, m68k_setup_auto_interrupt() should take a
function that returns int, too,
- Forgot to update forward declaration of q40_irq_handler(),
- Whitespace fixes
Signed-off-by: Geert Uytterhoeven
---
arch/m68k/include/asm/irq.h |4 ++--
arch/m68k/kernel/entry.S | 10 ++
arch/m68k/kernel/ints.c |9 +++--
arch/m68k/platform/68000/entry.S |2 +-
arch/m68k/platform/68000/ints.c |2 +-
arch/m68k/platform/68360/entry.S |4 ++--
arch/m68k/q40/q40ints.c |2 +-
7 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/arch/m68k/include/asm/irq.h b/arch/m68k/include/asm/irq.h
index 8d8e0f835275..fa7f079aeafa 100644
--- a/arch/m68k/include/asm/irq.h
+++ b/arch/m68k/include/asm/irq.h
@@ -60,8 +60,8 @@ struct irq_desc;
extern unsigned int m68k_irq_startup(struct irq_data *data);
extern unsigned int m68k_irq_startup_irq(unsigned int irq);
extern void m68k_irq_shutdown(struct irq_data *data);
-extern void m68k_setup_auto_interrupt(void (*handler)(unsigned int,
- struct pt_regs *));
+extern void m68k_setup_auto_interrupt(int (*handler)(unsigned int,
+struct pt_regs *));
extern void m68k_setup_user_interrupt(unsigned int vec, unsigned int cnt);
extern void m68k_setup_irq_controller(struct irq_chip *,
void (*handle)(unsigned int irq,
diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
index d35c2a22398a..ca355813ce51 100644
--- a/arch/m68k/kernel/entry.S
+++ b/arch/m68k/kernel/entry.S
@@ -289,7 +289,7 @@ ret_from_interrupt:
* Only the last interrupt leaving the kernel goes
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
> +#define smp_load_acquire(p, v)
> \
I R idiot!! :-)
---
arch/alpha/include/asm/barrier.h | 13 +++
arch/arc/include/asm/barrier.h| 13 +++
arch/arm/include/asm/barrier.h| 26 +
arch/arm64/include/asm/barrier.h | 28 +++
arch/avr32/include/asm/barrier.h | 12 ++
arch/blackfin/include/asm/barrier.h | 13 +++
arch/cris/include/asm/barrier.h | 13 +++
arch/frv/include/asm/barrier.h| 13 +++
arch/h8300/include/asm/barrier.h | 13 +++
arch/hexagon/include/asm/barrier.h| 13 +++
arch/ia64/include/asm/barrier.h | 43 +++
arch/m32r/include/asm/barrier.h | 13 +++
arch/m68k/include/asm/barrier.h | 13 +++
arch/metag/include/asm/barrier.h | 13 +++
arch/microblaze/include/asm/barrier.h | 13 +++
arch/mips/include/asm/barrier.h | 13 +++
arch/mn10300/include/asm/barrier.h| 13 +++
arch/parisc/include/asm/barrier.h | 13 +++
arch/powerpc/include/asm/barrier.h| 15
arch/s390/include/asm/barrier.h | 13 +++
arch/score/include/asm/barrier.h | 13 +++
arch/sh/include/asm/barrier.h | 13 +++
arch/sparc/include/asm/barrier_32.h | 13 +++
arch/sparc/include/asm/barrier_64.h | 13 +++
arch/tile/include/asm/barrier.h | 13 +++
arch/unicore32/include/asm/barrier.h | 13 +++
arch/x86/include/asm/barrier.h| 13 +++
arch/xtensa/include/asm/barrier.h | 13 +++
28 files changed, 423 insertions(+)
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index ce8860a0b32d..464139feee97 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -29,6 +29,19 @@ __asm__ __volatile__("mb": : :"memory")
#define smp_read_barrier_depends() do { } while (0)
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define set_mb(var, value) \
do { var = value; mb(); } while (0)
diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
index f6cb7c4ffb35..a779da846fb5 100644
--- a/arch/arc/include/asm/barrier.h
+++ b/arch/arc/include/asm/barrier.h
@@ -30,6 +30,19 @@
#define smp_wmb() barrier()
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define smp_mb__before_atomic_dec()barrier()
#define smp_mb__after_atomic_dec() barrier()
#define smp_mb__before_atomic_inc()barrier()
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 60f15e274e6d..4ada4720bdeb 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -53,10 +53,36 @@
#define smp_mb() barrier()
#define smp_rmb() barrier()
#define smp_wmb() barrier()
+
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1;
Re: [RFC] arch: Introduce new TSO memory barrier smp_tmb()
On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote:
> All this is leading me to suggest the following shortenings of names:
>
> smp_load_with_acquire_semantics() -> smp_load_acquire()
>
> smp_store_with_release_semantics() -> smp_store_release()
>
> But names aside, the above gets rid of explicit barriers on TSO architectures,
> allows ARM to avoid full DMB, and allows PowerPC to use lwsync instead of
> the heavier-weight sync.
A little something like this? Completely guessed at the arm/arm64/ia64
asm, but at least for those archs I found proper instructions (I hope),
for x86,sparc,s390 which are TSO we can do with a barrier and PPC like
said can do with the lwsync, all others fall back to using a smp_mb().
Should probably come with a proper changelog and an addition to _The_
document.
---
arch/alpha/include/asm/barrier.h | 13 +++
arch/arc/include/asm/barrier.h| 13 +++
arch/arm/include/asm/barrier.h| 26 +
arch/arm64/include/asm/barrier.h | 28 +++
arch/avr32/include/asm/barrier.h | 12 ++
arch/blackfin/include/asm/barrier.h | 13 +++
arch/cris/include/asm/barrier.h | 13 +++
arch/frv/include/asm/barrier.h| 13 +++
arch/h8300/include/asm/barrier.h | 13 +++
arch/hexagon/include/asm/barrier.h| 13 +++
arch/ia64/include/asm/barrier.h | 43 +++
arch/m32r/include/asm/barrier.h | 13 +++
arch/m68k/include/asm/barrier.h | 13 +++
arch/metag/include/asm/barrier.h | 13 +++
arch/microblaze/include/asm/barrier.h | 13 +++
arch/mips/include/asm/barrier.h | 13 +++
arch/mn10300/include/asm/barrier.h| 13 +++
arch/parisc/include/asm/barrier.h | 13 +++
arch/powerpc/include/asm/barrier.h| 15
arch/s390/include/asm/barrier.h | 13 +++
arch/score/include/asm/barrier.h | 13 +++
arch/sh/include/asm/barrier.h | 13 +++
arch/sparc/include/asm/barrier_32.h | 13 +++
arch/sparc/include/asm/barrier_64.h | 13 +++
arch/tile/include/asm/barrier.h | 13 +++
arch/unicore32/include/asm/barrier.h | 13 +++
arch/x86/include/asm/barrier.h| 13 +++
arch/xtensa/include/asm/barrier.h | 13 +++
28 files changed, 423 insertions(+)
diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index ce8860a0b32d..464139feee97 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -29,6 +29,19 @@ __asm__ __volatile__("mb": : :"memory")
#define smp_read_barrier_depends() do { } while (0)
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define set_mb(var, value) \
do { var = value; mb(); } while (0)
diff --git a/arch/arc/include/asm/barrier.h b/arch/arc/include/asm/barrier.h
index f6cb7c4ffb35..a779da846fb5 100644
--- a/arch/arc/include/asm/barrier.h
+++ b/arch/arc/include/asm/barrier.h
@@ -30,6 +30,19 @@
#define smp_wmb() barrier()
#endif
+#define smp_store_release(p, v)
\
+do { \
+ smp_mb(); \
+ ACCESS_ONCE(p) = (v); \
+} while (0)
+
+#define smp_load_acquire(p)\
+do { \
+ typeof(p) ___p1 = ACCESS_ONCE(p); \
+ smp_mb(); \
+ return ___p1; \
+} while (0)
+
#define smp_mb__before_atomic_dec()barrier()
#define smp_mb__after_atomic_dec() barrier()
#define smp_mb__before_atomic_inc()barrier()
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 60f15e274e6d..a804093d6891 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -53,10 +53,36 @@
#define smp_mb() barrier()
#define smp_rmb() barrier()
#define smp_wmb()
Re: linux-next: Tree for Oct 30 (include/xen/swiotlb-xen.h)
On 11/04/13 10:14, Stefano Stabellini wrote: > On Fri, 1 Nov 2013, Konrad Rzeszutek Wilk wrote: >> On Wed, Oct 30, 2013 at 11:44:51AM -0700, Randy Dunlap wrote: >>> On 10/30/13 00:45, Stephen Rothwell wrote: Hi all, News: I am now doing an arm multi_v7_defconfig build between each merge. Changes since 20131029: The arm defconfig build is fixed again. The net-next tree gained a conflict against the net tree. The xen-tip tree gained a conflict against the arm tree. The akpm-current tree gained a conflict against the tip tree and a build failure for which I reverted 3 commits. Various build problems from yesterday have been resolved. >>> >>> on x86_64: >> >> Stefano, please fix that. > > Thanks for the notification. I am appending the fix that I am about to > apply to xentip/linux-next. > > > commit bb5ebdb6a674c59cd7b5d159d6ca3c0084ee60e1 > Author: Stefano Stabellini > Date: Mon Nov 4 17:54:27 2013 + > > swiotlb-xen: missing include dma-direction.h > > Signed-off-by: Stefano Stabellini Thanks for both fixes. > diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h > index 7b64465..8b2eb93 100644 > --- a/include/xen/swiotlb-xen.h > +++ b/include/xen/swiotlb-xen.h > @@ -1,6 +1,7 @@ > #ifndef __LINUX_SWIOTLB_XEN_H > #define __LINUX_SWIOTLB_XEN_H > > +#include > #include > > extern int xen_swiotlb_init(int verbose, bool early); > -- -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12 released .. and no merge window yet .. and 4.0 plans?
On Mon, Nov 4, 2013 at 1:25 AM, Ingo Molnar wrote: > > * Linus Torvalds wrote: > >> So I may be pessimistic, but I'd expect many developers would go "Let's >> hunt bugs.. Wait. Oooh, shiny" and go off doing some new feature after >> all instead. Or just take that release off. >> >> But I do wonder.. Maybe it would be possible, and I'm just unfairly >> projecting my own inner squirrel onto other kernel developers. If we >> have enough heads-up that people *know* that for one release (and >> companies/managers know that too) the only patches that get accepted are >> the kind that fix bugs, maybe people really would have sufficient >> attention span that it could work. >> >> And the reason I mention "4.0" is that it would be a lovely time to do >> that. Roughly a years heads-up that "ok, after 3.19 (or whatever), we're >> doing a release with *just* fixes, and then that becomes 4.0". >> >> Comments? > > I think the biggest problem wouldn't even be the enforcement of > bugfixes-only during that 2.5 months period, or kernel developers > surviving such a long streak of boredom, but v3.19 would also probably be > a super-stressful release to maintainers, as everyone would try to cram > their feature in there. And if anything important misses that window then > it's a +5 months wait... I'd agree with that, but it wouldn't be limited to just the final non-bugfix release. It would be a year-long "shove as much as we can in" push, and I'd be fearful of doing any distro kernel based on any one of those releases. Clearly the subsystem maintainers would still be fighting the good fight, but I'm concerned they'd be overwhelmed and/or burnt out by the time 4.0 came around. > The other problem is that kernel developers who do development typically > fix their own bugs within a week or two. It's not developers that > typically determine the stability of a subsystem but _maintainers_, and > the primary method of stabilization is, beyond being careful when merging > a patch, is to remember/monitor breakages and not merge new feature > patches from a developer until fixable bugs are fixed by the developer. Right. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Allow NR_CPUS=1024
8192 maybe? Ingo Molnar wrote: > >* Russ Anderson wrote: > >> > Russ, does SGI (or anyone else that you know of) have x86 hardware >> > with more than 4096 CPUs? >> >> Yes. We have a system in the lab with 254 12-core IVB sockets for a >> total of 3048 cores. With HT is it 6096 cpus. > >It would then be nice to up MAXSMP to 6144 or so. > >Thanks, > > Ingo -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] perf tools: Add perf_event_max_sample_rate freq check
On Mon, Nov 04, 2013 at 12:06:10PM +0100, Jiri Olsa wrote: > hi, > adding the check for maximum allowed frequency rate > defined in perf_event_max_sample_rate. > > Plus procfs mountpoint reading code. Reachable here: > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/cc oops, ^^^ should be 'perf/max_rate' jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] usb: ffs: check quirk to pad epout buf size when not aligned to maxpacketsize
Hi Alan,
Appreciate your comments. Please, see my reply.
On 10/30/2013 10:35 AM, Alan Stern wrote:
On Wed, 30 Oct 2013, David Cohen wrote:
Check gadget.quirk_ep_out_aligned_size to decide if buffer size requires
to be aligned to maxpacketsize of an out endpoint. ffs_epfile_io() needs
to pad epout buffer to match above condition if quirk is found.
Signed-off-by: David Cohen
---
drivers/usb/gadget/f_fs.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 75e4b78..b49dd55 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -755,10 +755,12 @@ static ssize_t ffs_epfile_io(struct file *file,
char __user *buf, size_t len, int read)
{
struct ffs_epfile *epfile = file->private_data;
+ struct usb_gadget *gadget = epfile->ffs->gadget;
struct ffs_ep *ep;
char *data = NULL;
ssize_t ret;
int halt;
+ size_t orig_len = len;
goto first_try;
do {
@@ -794,6 +796,21 @@ first_try:
goto error;
}
+ /*
+* Controller requires buffer size to be aligned to
+* maxpacketsize of an out endpoint.
+*/
+ if (gadget->quirk_ep_out_aligned_size && read &&
+ !IS_ALIGNED(len, ep->ep->desc->wMaxPacketSize)) {
IS_ALIGNED works only when the second argument is a power of 2.
Interrupt endpoints are not required to have maxpacket sizes that are
powers of 2. Does this code ever get used for an interrupt endpoint?
That's a good point. It won't use interrupt ep on the case I am working
on, but f_fs allows it. I'll cover both cases in next patchset.
+ size_t old_len = len;
Why add old_len here when you added orig_len above?
See below.
+ len = roundup(orig_len,
+ (size_t)ep->ep->desc->wMaxPacketSize);
+ if (unlikely(data) && len > old_len) {
If the original value wasn't aligned, how can len fail to be > old_len?
This code is inside a loop. There is an unlikely case explained in the
end to loop again if ep got disabled or changed while acquiring mutex.
If that happens, I want to avoid to re-allocate buffer if previous size
was already enough. Since 'len' gets updated when aligning buf size, we
need to keep track of 'orig_len' to do only minimum necessary pad on
new alignment. 'old_len' is used to save previous value to decide for
new allocation or not. But maybe I should change it to something more
accurate like 'buf_size' or 'alloc_size'.
Br, David Cohen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: scsi-mq + open-iscsi support patches..?
On Sat, 2013-11-02 at 16:10 +, Jayamohan Kallickal wrote: > >> On a related note, some iscsi vendor has been hitting a crash with > >> your tree. > > >I got an email from Jayamohan recently, but the OOPs did not appear to be > >scsi-mq related.. > > I do see the crash on my Ubuntu VM running on VirtualBox but don't see the > crash on a Standalone system. > Attaching the screenshot > Hi Jayamohan, Care to enable the virtual serial port for this VM in order to grab the full dmesg output..? Also, an idea of what SATA emulation is being used here would be helpful as well. (eg: lspci -vvv for the ATA device on the running system) --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On 11/04, Oleg Nesterov wrote:
>
> On 11/04, Oleg Nesterov wrote:
> >
> > On 11/04, Oleg Nesterov wrote:
> > >
> > > But in any case, I strongly believe that it doesn't make any sense to
> > > rely on tu->inode in get_user_vaddr().
> >
> > Hmm. But I forgot about the case when you probe the function in libc
> > and want to dump the variable in libc...
> >
> > So probably I was wrong and this all needs more thinking. Damn.
> > Perhaps we really need to pass @file/offset, but it is not clear what
> > we can do with bss/anon-mapping.
>
> Or. Not that I really like this, but just for discussion...
>
> How about
>
> static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
> addr)
> {
> return (void __force __user *)addr + instruction_pointer(regs);
> }
>
> ?
>
> This should solve the problems with relocations/randomization/bss.
>
> The obvious disadvantage is that it is not easy to calculate the
> offset we need to pass as an argument, it depends on the probed
> function.
forgot to mention... and instruction_pointer() can't work in ret-probe,
we need to pass the "unsigned long func" arg somehow...
>
> And this still doesn't allow to, say, probe the executable but read
> the data from libc. Unless, again, we attach to the running process
> or randomize_va_space = 0, so we can know it in advance. But otherwise
> I do not think there is any solution.
>
> Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Solving M produces N consumers scalability problem
Anatol Pomozov writes: > > One idea is not to use the spin_lock. It is the 'fair spin_lock' that > has scalability problems > http://pdos.csail.mit.edu/papers/linux:lock.pdf Maybe lockless > datastructures can help here? The standard spin lock is already improved. But better locks just give you a small advantage, they don't solve the real scaling problem. > > Another idea is avoid global datasctructures but I have a few > questions here. Let's say we want to use per-CPU lists. But the > problem is that producers/consumers are not distributed across all > CPUs. Some CPU might have too many producers, some other might not > have consumers at all. So we need some kind of migration from hot CPU > to the cold one. What is the best way to achieve it? Are there any > examples how to do this? Any other ideas? per cpu is the standard approach, but usually overkill. Also requires complex code to drain etc. Some older patches also use per node, but that works very poorly these days (nodes are far too big) One way I like is to simply use a global (allocated) array of queues, sized by total number of possible cpus (but significantly smaller) and use the cpu number as a hash into the array. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)
On 11/04, Oleg Nesterov wrote:
>
> On 11/04, Oleg Nesterov wrote:
> >
> > But in any case, I strongly believe that it doesn't make any sense to
> > rely on tu->inode in get_user_vaddr().
>
> Hmm. But I forgot about the case when you probe the function in libc
> and want to dump the variable in libc...
>
> So probably I was wrong and this all needs more thinking. Damn.
> Perhaps we really need to pass @file/offset, but it is not clear what
> we can do with bss/anon-mapping.
Or. Not that I really like this, but just for discussion...
How about
static void __user *get_user_vaddr(struct pt_regs *regs, unsigned long
addr)
{
return (void __force __user *)addr + instruction_pointer(regs);
}
?
This should solve the problems with relocations/randomization/bss.
The obvious disadvantage is that it is not easy to calculate the
offset we need to pass as an argument, it depends on the probed
function.
And this still doesn't allow to, say, probe the executable but read
the data from libc. Unless, again, we attach to the running process
or randomize_va_space = 0, so we can know it in advance. But otherwise
I do not think there is any solution.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Avoid needless loop in sdhci_irq() for Card Interrupt
[Patch ping #3: anyone interested in making sdhci_irq a bit faster?] Hi all, I've discovered that the sdhci_irq() function needlessly iterates re-reading the interrupt status and doing nothing (until it runs out of max_loops) when it handles the "Card Interrupt" status in the interrupt status register. The reason is that the "Card Interrupt" bit is not cleared until the sdhci_irq() calls mmc_signal_sdio_irq(), so if Card Interrupt was asserted, re-reading the interrupt status will find this bit set over and over, even if no other bits are reported. The fix: ignore Card Interrupt bits in the interrupt status if we already know that mmc_signal_sdio_irq() is going to be called at the end of sdhci_irq(). Signed-off-by: Alexey Neyman commit 7f23315b344ca51ddf22a78f326f88404fa8c81d Author: Alexey Neyman Date: Wed Oct 9 22:23:54 2013 -0700 Avoid a loop in sdhci.c. diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7a7fb4f..a83cd1b 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2491,6 +2491,14 @@ again: result = IRQ_HANDLED; intmask = sdhci_readl(host, SDHCI_INT_STATUS); + + /* + * If we know we'll call the driver to signal SDIO IRQ, disregard + * further indications of Card Interrupt in the status to avoid a + * needless loop. + */ + if (cardint) + intmask &= ~SDHCI_INT_CARD_INT; if (intmask && --max_loops) goto again; out:
Re: [PATCH v2] mmc: fix host release issue after discard operation
On 10/26/2013 11:03 AM, Ray Jui wrote:
Under function mmc_blk_issue_rq, after an MMC discard operation,
the MMC request data structure may be freed in memory. Later in
the same function, the check of req->cmd_flags & MMC_REQ_SPECIAL_MASK
is dangerous and invalid. It causes the MMC host not to be released
when it should
This patch fixes the issue by marking the special request down before
the discard/flush operation
Reported by: Harold (SoonYeal) Yang
Signed-off-by: Ray Jui
Reviewed-by: Seungwon Jeon
---
drivers/mmc/card/block.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 1a3163f..4e8212c 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1959,6 +1959,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
struct mmc_card *card = md->queue.card;
struct mmc_host *host = card->host;
unsigned long flags;
+ unsigned int cmd_flags = req ? req->cmd_flags : 0;
if (req && !mq->mqrq_prev->req)
/* claim host only for the first request */
@@ -1974,7 +1975,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
}
mq->flags &= ~MMC_QUEUE_NEW_REQUEST;
- if (req && req->cmd_flags & REQ_DISCARD) {
+ if (cmd_flags & REQ_DISCARD) {
/* complete ongoing async transfer before issuing discard */
if (card->host->areq)
mmc_blk_issue_rw_rq(mq, NULL);
@@ -1983,7 +1984,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
ret = mmc_blk_issue_secdiscard_rq(mq, req);
else
ret = mmc_blk_issue_discard_rq(mq, req);
- } else if (req && req->cmd_flags & REQ_FLUSH) {
+ } else if (cmd_flags & REQ_FLUSH) {
/* complete ongoing async transfer before issuing flush */
if (card->host->areq)
mmc_blk_issue_rw_rq(mq, NULL);
@@ -1999,7 +2000,7 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq, struct
request *req)
out:
if ((!req && !(mq->flags & MMC_QUEUE_NEW_REQUEST)) ||
-(req && (req->cmd_flags & MMC_REQ_SPECIAL_MASK)))
+(cmd_flags & MMC_REQ_SPECIAL_MASK))
/*
* Release host when there are no more requests
* and after special request(discard, flush) is done.
Hi Seungwon/Chris,
Have you got a chance to review the MMC discard patch V2? The patch v2
makes changes from v1 based on Seungwon's review comments.
Thanks,
Ray Jui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] extcon-gpio: add devicetree support.
On Fri, Nov 01, 2013 at 10:16:44AM -0700, Mark Rutland wrote: > On Fri, Nov 01, 2013 at 09:50:05AM +, NeilBrown wrote: > > + - label: name for connector. If not given, device name is used. > Are extcon devices ever used standalone? If so, why? They are sometimes used for things that don't have/need any other software representation in the system like detection of attachment of covers or as bundles for other connectors (like the Apple 30 pin cables, they have the base connector with multiple possible things connected on it). > If not I see _no_ reason at all for the label property. If a userspace > application needs to detect the presence of a particular external connector, > it > will need to know this in relation to the device the external connectors are > attached to. In that case the application should find that device and traverse > its set of extcon devices. The names for the external connections will be a > property of the device, not the extcon devices themselves (along hte same > lines > as clocks), and need not be a property of the extcon device. This is often done for user display purposes rather than for the application and is sometimes done from the perspective of "what's plugged into my system" (eg, helping someone cable up their system) rather than from the point of view of using an individual device. For example the HDA spec connector objects include information like the connector label (ie, writing on the case) and colour as part of the object for the connector and DMI does similar things for PCI slots. signature.asc Description: Digital signature
Re: [PATCH v9 01/18] arm: make SWIOTLB available
On Wed, 30 Oct 2013, Stefano Stabellini wrote:
> On Tue, 29 Oct 2013, Russell King - ARM Linux wrote:
> > So... what I'm saying is please fix xgmac to use the DMA API properly
> > rather than working around such problems. :)
>
> OK.
> Would the appended patch fix your concerns?
ping?
> ---
>
> arm: make SWIOTLB available
>
> IOMMU_HELPER is needed because SWIOTLB calls iommu_is_span_boundary,
> provided by lib/iommu_helper.c.
>
> Signed-off-by: Stefano Stabellini
> Reviewed-by: Konrad Rzeszutek Wilk
>
> Changes in v9:
> - remove uneeded include asm/cacheflush.h;
> - just return 0 if !dev->dma_mask in dma_capable.
>
> ---
> arch/arm/Kconfig |6 ++
> arch/arm/include/asm/dma-mapping.h | 33 +
> 2 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 1ad6fb6..b08374f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1872,6 +1872,12 @@ config CC_STACKPROTECTOR
> neutralized via a kernel panic.
> This feature requires gcc version 4.2 or above.
>
> +config SWIOTLB
> + def_bool y
> +
> +config IOMMU_HELPER
> + def_bool SWIOTLB
> +
> config XEN_DOM0
> def_bool y
> depends on XEN
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index 5b579b9..1ad2c17 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -86,6 +86,39 @@ static inline dma_addr_t virt_to_dma(struct device *dev,
> void *addr)
> }
> #endif
>
> +static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
> +{
> + unsigned int offset = paddr & ~PAGE_MASK;
> + return pfn_to_dma(dev, __phys_to_pfn(paddr)) + offset;
> +}
> +
> +static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t
> dev_addr)
> +{
> + unsigned int offset = dev_addr & ~PAGE_MASK;
> + return __pfn_to_phys(dma_to_pfn(dev, dev_addr)) + offset;
> +}
> +
> +static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t
> size)
> +{
> + u64 limit, mask;
> +
> + if (!dev->dma_mask)
> + return 0;
> +
> + mask = *dev->dma_mask;
> +
> + limit = (mask + 1) & ~mask;
> + if (limit && size > limit)
> + return 0;
> +
> + if ((addr | (addr + size - 1)) & ~mask)
> + return 0;
> +
> + return 1;
> +}
> +
> +static inline void dma_mark_clean(void *addr, size_t size) { }
> +
> /*
> * DMA errors are defined by all-bits-set in the DMA address.
> */
> --
> 1.7.2.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] sched: Refactor iowait accounting
On Mon, Nov 04, 2013 at 06:34:23PM +0100, Frederic Weisbecker wrote: > On Sun, Oct 20, 2013 at 01:10:06PM +0200, Andreas Mohr wrote: > > In case of high update traffic of parts guarded by rq->iowait_lock > > (is that a relevant case?), > > > > it might be useful to merely grab all relevant values into helper vars > > (i.e., establish a consistent "view" on things), now, start, nr_iowait etc. > > - > > this would enable us to do ktime_sub(), ktime_add() calculations > > *once*, after the fact. Drawback would be that this reduces seqlock > > guard scope (would not be active any more during runtime spent for > > calculations, > > i.e. another update may happen during that calculation time), > > but then that function's purpose merely is to provide a *consistent > > one-time probe* of a continually updated value anyway, so it does not > > matter if we happen to return values of one update less > > than is already available. > > I'm not sure I really understand what you mean here. But I don't think we can > do the > iowait_start/iowait_time probe only once. The retry part is necessary to make > sure that we have coherent results against a given update sequence. Otherwise > we > need to use pure exclusive locks, like spinlocks. If we find out that there > are issues > wrt. readers starvations or livelocks, may be we'll do this but I believe > that won't > be needed. Seqlocks are of course a good way to properly guard consistency while updates ongoing, and such handling *is* required like is being done here (or, alternatively similar to that). I was just indicating that it might make sense to draw a minimalist-data watch "view" from some updated-values area, to enable then doing the final (and a possibly expensive!) calculation *post-seqlock*, i.e. processing these stack-local helpers only once values consistency was successfully verified. In your case here, the extraneous inner-seqlock handling merely consists of few subtractions/additions, so it quite likely does not make sense to actively move those values over into stack-local *copies* (especially since having ongoing update activity occurring probably won't be a hotpath case), but for some other cases of seqlock use that might be useful, to minimize within-seqlock handling overhead. > I think I'm going to respin this series but move back the iowait time update > part to > the idle code. The update made in io_schedule() doesn't work since we really > need it > to account iowait time when the CPU is idle only: idle time accounting itself > depend > on it, and the callers of get_...time_us() rely on that too. Plus doing the > update > only when the CPU is idle will result in less overhead. OK, probably (I haven't quite fully analyzed it). But it would be good to achieve rectifying handling to make calculation of cumulative I/O wait time of a runqueue element properly account for the asymmetric case (this-initiating-cpu that-ending-cpu). And frankly I'm still confused about what kind of valuable property exactly it is that we're measuring here... (I/O wait time while CPU idle, especially in the distributed-SMP case). The criteria seem murky. Hmm, unless... we're talking a truly properly CPU-agnostic "global" accounting which properly registers the delta which extends from start-I/O with *all CPUs now idle* to that I/O being finished (on *whichever* CPU!!), *and with all intermediate time periods of _any_ CPUs non-idle properly excluded*. So, from my limited analysis/understanding, a precise implementation of that accounting to me seems to have (at least?) the following responsibilities: - ensure properly isolated *per-runqueue-element attribution* of I/O-while-CPUs-fully-idle cumulative time, belonging to *that* runqueue element - ensure an accounting which properly starts attributing *any* ongoing I/O activities to idle-time I/O once all CPUs went idle - ensure an accounting which does proper *exclusion* of any intermediate *non-idle* periods (i.e., whenever *even a single CPU* exited idle state) That AFAICS is the only way that this accounting would make sense on a non-UP system. Right? Or what exactly would the purpose/justification/implementation of such idle-CPU I/O wait time accounting be, especially on SMP? And try to view it in that light: 1. what is the maximally correct way to implement such accounting? 2. how to do that maximally efficiently? 3. with in-kernel handling now perfect, how to accommodate existing (potentially mal-defined) user-side APIs? Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] perf tools: Add perf_data_file__write mmap support
When recording raw_syscalls for the entire system, e.g.,
perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 10
you end up with a negative feedback loop as perf itself calls
write() fairly often. This patch handles the problem by mmap'ing the
file in chunks of 64M at a time and copies events from the event buffers
to the file avoiding write system calls.
Before (with write syscall):
# time ./perf.old record -e raw_syscalls:*,sched:sched_switch -a -- sleep 10
[ perf record: Woken up 0 times to write data ]
[ perf record: Captured and wrote 914.717 MB perf.data (~39964591 samples) ]
real0m11.390s
user0m2.029s
sys 0m9.311s
After (using mmap):
# time ./perf record -e raw_syscalls:*,sched:sched_switch -a -- sleep 10
[ perf record: Woken up 74 times to write data ]
[ perf record: Captured and wrote 19.231 MB perf.data (~840219 samples) ]
real0m10.182s
user0m0.067s
sys 0m0.121s
In addition to perf-trace benefits using mmap lowers the overhead of
perf-record.
v3: moved David's code into perf_data_file object, also used
most of his changelog
Original-patch-by: David Ahern
Signed-off-by: Jiri Olsa
Cc: Ingo Molnar
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Namhyung Kim
Cc: Mike Galbraith
Cc: Stephane Eranian
Cc: David Ahern
Cc: Adrian Hunter
---
tools/perf/builtin-record.c | 11 ++---
tools/perf/util/data.c | 100 +++-
tools/perf/util/data.h | 8
3 files changed, 112 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 5201677..45722fc 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -240,12 +240,8 @@ out:
static int process_buildids(struct perf_record *rec)
{
- struct perf_data_file *file = >file;
struct perf_session *session = rec->session;
-
- u64 size = lseek(file->fd, 0, SEEK_CUR);
- if (size == 0)
- return 0;
+ u64 size = perf_data_file__size(>file);
return __perf_session__process_events(session,
rec->post_processing_offset,
size -
rec->post_processing_offset,
@@ -535,6 +531,11 @@ static int __cmd_record(struct perf_record *rec, int argc,
const char **argv)
if (quiet || signr == SIGUSR1)
return 0;
+ if (perf_data_file__munmap(file)) {
+ pr_err("data file unmap failed\n");
+ goto out_delete_session;
+ }
+
fprintf(stderr, "[ perf record: Woken up %ld times to write data ]\n",
waking);
/*
diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
index cce1256..af5d644 100644
--- a/tools/perf/util/data.c
+++ b/tools/perf/util/data.c
@@ -4,10 +4,13 @@
#include
#include
#include
+#include
#include "data.h"
#include "util.h"
+#define MMAP_WRITE_SIZE (64*1024*1024)
+
static bool check_pipe(struct perf_data_file *file)
{
struct stat st;
@@ -111,6 +114,9 @@ int perf_data_file__open(struct perf_data_file *file)
if (!file->path)
file->path = "perf.data";
+ if (!file->mmap_size)
+ file->mmap_size = MMAP_WRITE_SIZE;
+
return open_file(file);
}
@@ -119,8 +125,70 @@ void perf_data_file__close(struct perf_data_file *file)
close(file->fd);
}
-ssize_t perf_data_file__write(struct perf_data_file *file,
- void *buf, size_t size)
+static int do_mmap(struct perf_data_file *file, u64 offset)
+{
+ u64 mmap_size = file->mmap_size;
+
+ file->mmap_off = offset % mmap_size;
+ file->mmap_foff = (offset / mmap_size) * mmap_size;
+
+ file->mmap_addr = mmap(NULL, mmap_size,
+ PROT_WRITE | PROT_READ,
+ MAP_SHARED,
+ file->fd,
+ file->mmap_foff);
+
+ if (file->mmap_addr == MAP_FAILED) {
+ pr_err("mmap failed: %d: %s\n", errno, strerror(errno));
+ return -1;
+ }
+
+ /* Expand file to include this mmap segment. */
+ if (ftruncate(file->fd, file->mmap_foff + file->mmap_size) != 0) {
+ pr_err("ftruncate failed: %d: %s\n", errno, strerror(errno));
+ return -1;
+ }
+
+ return 0;
+}
+
+static ssize_t write_mmap(struct perf_data_file *file,
+ void *buf, size_t size)
+{
+ ssize_t total = size;
+
+ if (!file->mmap_addr) {
+ off_t offset = lseek(file->fd, 0, SEEK_CUR);
+ if (offset < 0)
+ return -1;
+
+ if (do_mmap(file, offset))
+ return -1;
+ }
+
+ while (size) {
+ u64 remain = file->mmap_size - file->mmap_off;
+
+ if (size > remain) {
+ memcpy(file->mmap_addr + file->mmap_off, buf, remain);
+
[PATCH 0/2] perf record: mmap output file - v3
hi, after discussion with David, sending his change updated into the new data file object. David's original post: http://marc.info/?l=linux-kernel=138180575328977=2 Here's the change: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/mmap1 thanks, jirka Signed-off-by: Jiri Olsa Cc: Ingo Molnar Cc: Frederic Weisbecker Cc: Peter Zijlstra Cc: Namhyung Kim Cc: Mike Galbraith Cc: Stephane Eranian Cc: David Ahern Cc: Adrian Hunter --- Jiri Olsa (2): perf tools: Add perf_data__write implementation into perf_data_file object perf tools: Add perf_data_file__write mmap support tools/perf/builtin-record.c | 49 ++-- tools/perf/util/data.c | 116 +++ tools/perf/util/data.h | 23 ++--- 3 files changed, 152 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] perf tools: Add perf_data__write implementation into perf_data_file object
Adding perf_data__write implementation into perf_data_file
object. This interface is now used within record command
to store data.
Signed-off-by: Jiri Olsa
Cc: Ingo Molnar
Cc: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Namhyung Kim
Cc: Mike Galbraith
Cc: Stephane Eranian
Cc: David Ahern
Cc: Adrian Hunter
---
tools/perf/builtin-record.c | 38 ++
tools/perf/util/data.c | 20
tools/perf/util/data.h | 15 ---
3 files changed, 42 insertions(+), 31 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index ab8d15e..5201677 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -82,24 +82,17 @@ static void advance_output(struct perf_record *rec, size_t
size)
rec->bytes_written += size;
}
-static int write_output(struct perf_record *rec, void *buf, size_t size)
+static ssize_t perf_record__write(struct perf_record *rec,
+ void *buf, size_t size)
{
- struct perf_data_file *file = >file;
-
- while (size) {
- int ret = write(file->fd, buf, size);
-
- if (ret < 0) {
- pr_err("failed to write perf data, error: %m\n");
- return -1;
- }
-
- size -= ret;
- buf += ret;
+ struct perf_session *session = rec->session;
+ ssize_t ret;
- rec->bytes_written += ret;
- }
+ ret = perf_data_file__write(session->file, buf, size);
+ if (ret < 0)
+ return -1;
+ rec->bytes_written += ret;
return 0;
}
@@ -109,10 +102,7 @@ static int process_synthesized_event(struct perf_tool
*tool,
struct machine *machine __maybe_unused)
{
struct perf_record *rec = container_of(tool, struct perf_record, tool);
- if (write_output(rec, event, event->header.size) < 0)
- return -1;
-
- return 0;
+ return perf_record__write(rec, event, event->header.size);
}
static int perf_record__mmap_read(struct perf_record *rec,
@@ -137,7 +127,7 @@ static int perf_record__mmap_read(struct perf_record *rec,
size = md->mask + 1 - (old & md->mask);
old += size;
- if (write_output(rec, buf, size) < 0) {
+ if (perf_record__write(rec, buf, size) < 0) {
rc = -1;
goto out;
}
@@ -147,7 +137,7 @@ static int perf_record__mmap_read(struct perf_record *rec,
size = head - old;
old += size;
- if (write_output(rec, buf, size) < 0) {
+ if (perf_record__write(rec, buf, size) < 0) {
rc = -1;
goto out;
}
@@ -322,8 +312,8 @@ static struct perf_event_header finished_round_event = {
static int perf_record__mmap_read_all(struct perf_record *rec)
{
- int i;
- int rc = 0;
+ struct perf_session *session = rec->session;
+ int i, rc = 0;
for (i = 0; i < rec->evlist->nr_mmaps; i++) {
if (rec->evlist->mmap[i].base) {
@@ -335,7 +325,7 @@ static int perf_record__mmap_read_all(struct perf_record
*rec)
}
if (perf_header__has_feat(>session->header, HEADER_TRACING_DATA))
- rc = write_output(rec, _round_event,
+ rc = perf_data_file__write(session->file, _round_event,
sizeof(finished_round_event));
out:
diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
index 7d09faf..cce1256 100644
--- a/tools/perf/util/data.c
+++ b/tools/perf/util/data.c
@@ -118,3 +118,23 @@ void perf_data_file__close(struct perf_data_file *file)
{
close(file->fd);
}
+
+ssize_t perf_data_file__write(struct perf_data_file *file,
+ void *buf, size_t size)
+{
+ ssize_t total = size;
+
+ while (size) {
+ ssize_t ret = write(file->fd, buf, size);
+
+ if (ret < 0) {
+ pr_err("failed to write perf data, error: %m\n");
+ return -1;
+ }
+
+ size -= ret;
+ buf += ret;
+ }
+
+ return total;
+}
diff --git a/tools/perf/util/data.h b/tools/perf/util/data.h
index 8c2df80..02c53dc 100644
--- a/tools/perf/util/data.h
+++ b/tools/perf/util/data.h
@@ -9,12 +9,12 @@ enum perf_data_mode {
};
struct perf_data_file {
- const char *path;
- int fd;
- bool is_pipe;
- bool force;
- unsigned long size;
- enum perf_data_mode mode;
+ const char *path;
+ int fd;
+ bool is_pipe;
+ bool force;
+ unsigned longsize;
+ enum perf_data_mode mode;
};
static inline bool perf_data_file__is_read(struct perf_data_file *file)
@@ -44,5
[PATCH 3/9] KEYS: struct key_preparsed_payload should have two payload pointers
struct key_preparsed_payload should have two payload pointers to correspond
with those in struct key.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/asymmetric_type.c |2 +-
crypto/asymmetric_keys/x509_public_key.c |2 +-
include/linux/key-type.h |2 +-
security/keys/key.c |6 --
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/crypto/asymmetric_keys/asymmetric_type.c
b/crypto/asymmetric_keys/asymmetric_type.c
index c1fe0fcee8e3..21960a4e74e8 100644
--- a/crypto/asymmetric_keys/asymmetric_type.c
+++ b/crypto/asymmetric_keys/asymmetric_type.c
@@ -156,7 +156,7 @@ static void asymmetric_key_free_preparse(struct
key_preparsed_payload *prep)
pr_devel("==>%s()\n", __func__);
if (subtype) {
- subtype->destroy(prep->payload);
+ subtype->destroy(prep->payload[0]);
module_put(subtype->owner);
}
kfree(prep->type_data[1]);
diff --git a/crypto/asymmetric_keys/x509_public_key.c
b/crypto/asymmetric_keys/x509_public_key.c
index f83300b6e8c1..ae3de8bfaa70 100644
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -256,7 +256,7 @@ static int x509_key_preparse(struct key_preparsed_payload
*prep)
__module_get(public_key_subtype.owner);
prep->type_data[0] = _key_subtype;
prep->type_data[1] = cert->fingerprint;
- prep->payload = cert->pub;
+ prep->payload[0] = cert->pub;
prep->description = desc;
prep->quotalen = 100;
diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index 88503dca2a57..d2b4845d74bf 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -41,7 +41,7 @@ struct key_construction {
struct key_preparsed_payload {
char*description; /* Proposed key description (or NULL) */
void*type_data[2]; /* Private key-type data */
- void*payload; /* Proposed payload */
+ void*payload[2];/* Proposed payload */
const void *data; /* Raw data */
size_t datalen;/* Raw datalen */
size_t quotalen; /* Quota length for proposed payload */
diff --git a/security/keys/key.c b/security/keys/key.c
index 4ea216652d52..64dc9cf6848e 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -1049,10 +1049,12 @@ int generic_key_instantiate(struct key *key, struct
key_preparsed_payload *prep)
if (ret == 0) {
key->type_data.p[0] = prep->type_data[0];
key->type_data.p[1] = prep->type_data[1];
- rcu_assign_keypointer(key, prep->payload);
+ rcu_assign_keypointer(key, prep->payload[0]);
+ key->payload.data2[1] = prep->payload[1];
prep->type_data[0] = NULL;
prep->type_data[1] = NULL;
- prep->payload = NULL;
+ prep->payload[0] = NULL;
+ prep->payload[1] = NULL;
}
pr_devel("<==%s() = %d\n", __func__, ret);
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/6] gpio: davinci: use irqdomain
Hi Prabhakar Lad,
On 11/02/2013 05:39 PM, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> This patch converts the davinci gpio driver to use irqdomain
> support.
This patch needs to be splitted in two:
1) add IRQ domain support
2) remove intc_irq_num
>
> Signed-off-by: Lad, Prabhakar
> ---
> arch/arm/mach-davinci/da830.c |1 -
> arch/arm/mach-davinci/da850.c |1 -
> arch/arm/mach-davinci/dm355.c |1 -
> arch/arm/mach-davinci/dm365.c |1 -
> arch/arm/mach-davinci/dm644x.c |1 -
> arch/arm/mach-davinci/dm646x.c |1 -
> drivers/gpio/gpio-davinci.c| 49
> ++--
> include/linux/platform_data/gpio-davinci.h |3 +-
> 8 files changed, 32 insertions(+), 26 deletions(-)
>
[...]
>
> int __init dm646x_gpio_register(void)
> diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
> index 95c6df1..bcb6d8d 100644
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -292,7 +293,7 @@ gpio_irq_handler(unsigned irq, struct irq_desc *desc)
> __raw_writel(status, >intstat);
>
> /* now demux them to the right lowlevel handler */
> - n = d->irq_base;
> + n = irq_find_mapping(d->irq_domain, 0);
Sorry, but I don't understand why have you used <0> as hwirq?
All below logic may not work in case if we switch to use Linear IRQ domain :(
- irq_create_mapping() may return ANY Linux IRQ number. It means, for
example, for bank0(ngpio=32)[0] it may return Linux_IRQ=200 or 201 or any other.
Also, for bank3(ngpio=16)[0] it may return Linux_IRQ=150, etc.
- More over, if you call irq_create_mapping() 32 times you may NOT get
sequential Linux_IRQ numbers.
So, the better sequence here can be smth. as below
(I can't verify it - my HW support only unbanked IRQs):
if (irq & 1)
mask <<= 16;
while (1) {
u32 status;
int bit;
/* ack any irqs */
status = __raw_readl(>intstat) & mask;
if (!status)
break;
__raw_writel(status, >intstat);
/* now demux them to the right lowlevel handler */
while (status) {
bit = __ffs(status);
status &= ~(1 << bit);
generic_handle_irq(irq_find_mapping(d->irq_domain,
bit));
}
}
> if (irq & 1) {
> n += 16;
> status >>= 16;
> @@ -313,10 +314,7 @@ static int gpio_to_irq_banked(struct gpio_chip *chip,
> unsigned offset)
> {
> struct davinci_gpio_controller *d = chip2controller(chip);
>
> - if (d->irq_base >= 0)
> - return d->irq_base + offset;
> - else
> - return -ENODEV;
> + return irq_find_mapping(d->irq_domain, offset);
I think you can use irq_create_mapping() here instead of
irq_find_mapping(), so IRQ will be mapped/allocated on demand.
Also, it seems, above code may crash in case if SoC has >1 GPIO banks and
gpio_unbanked > 0 and someone will call gpio_to_irq(>31).
> }
>
> static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
> @@ -373,6 +371,7 @@ static int davinci_gpio_irq_setup(struct platform_device
> *pdev)
> struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
> struct davinci_gpio_platform_data *pdata = dev->platform_data;
> struct davinci_gpio_regs __iomem *g;
> + int gpio_irq = 0;
>
> ngpio = pdata->ngpio;
> res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
> @@ -402,9 +401,15 @@ static int davinci_gpio_irq_setup(struct platform_device
> *pdev)
>*/
> for (gpio = 0, bank = 0; gpio < ngpio; bank++, gpio += 32) {
> chips[bank].chip.to_irq = gpio_to_irq_banked;
> - chips[bank].irq_base = pdata->gpio_unbanked
> - ? -EINVAL
> - : (pdata->intc_irq_num + gpio);
> + if (!pdata->gpio_unbanked) {
> + chips[bank].irq_domain =
> + irq_domain_add_linear(NULL, 32,
Use chips[i].chip.ngpio here instead of const 32?
> + _domain_simple_ops,
Pass _gpio_irq_ops (see below)
> + NULL);
Pass [bank] as host_data and use .map() callback (see below)
> +
> + if (!chips[bank].irq_domain)
> + return -ENOMEM;
> + }
> }
>
> /*
> @@ -445,9 +450,7 @@ static int davinci_gpio_irq_setup(struct platform_device
> *pdev)
>* Or, AINTC can handle IRQs for banks of
Re: [PATCH v4 4/6] gpio: davinci: add OF support
Hi Prabhakar Lad,
On 11/02/2013 05:39 PM, Lad, Prabhakar wrote:
From: KV Sujith
This patch adds OF parser support for davinci gpio
driver and also appropriate documentation in gpio-davinci.txt
located at Documentation/devicetree/bindings/gpio/.
I worry, do we need to have gpio_chip.of_xlate() callback implemented?
- From one side, Davinci GPIO controller in DT described by one entry
which defines number of supported GPIOs as "ti,ngpio = <144>;"
- From other side, on Linux level more than one gpio_chip objects are
instantiated (one per each 32 GPIO).
How the standard GPIO biding will work in this case? .. And will they?
Linus, I'd very appreciate if you will be able to clarify this point.
Signed-off-by: KV Sujith
Signed-off-by: Philip Avinash
[prabhakar.cse...@gmail.com: simplified the OF code, removed
unnecessary DT property and also simplified
the commit message]
Signed-off-by: Lad, Prabhakar
---
.../devicetree/bindings/gpio/gpio-davinci.txt | 32
drivers/gpio/gpio-davinci.c| 54 ++--
2 files changed, 83 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
new file mode 100644
index 000..55aae1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -0,0 +1,32 @@
+Davinci GPIO controller bindings
+
+Required Properties:
+- compatible: should be "ti,dm6441-gpio"
+
+- reg: Physical base address of the controller and the size of memory mapped
+ registers.
+
+- gpio-controller : Marks the device node as a gpio controller.
+
+- interrupts: Array of GPIO interrupt number.
May be meaning of property need to be extended, because,
as of now, only banked or unbanked IRQs are supported - and not both.
+
+- ti,ngpio: The number of GPIO pins supported.
+
+- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual
interrupt
+line to processor.
Should interrupt-controller; specifier be added here?
+
+Example:
+
+gpio: gpio@1e26000 {
+ compatible = "ti,dm6441-gpio";
+ gpio-controller;
+ reg = <0x226000 0x1000>;
+ interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
+ 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH
+ 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH
+ 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH
+ 50 IRQ_TYPE_EDGE_BOTH>;
+ ti,ngpio = <144>;
+ ti,davinci-gpio-irq-base = <101>;
^^ Is it still needed?
+ ti,davinci-gpio-unbanked = <0>;
+};
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index bcb6d8d..bb20a39 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -17,6 +17,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -134,6 +137,40 @@ davinci_gpio_set(struct gpio_chip *chip, unsigned offset,
int value)
__raw_writel((1 << offset), value ? >set_data : >clr_data);
}
+static struct davinci_gpio_platform_data *
+davinci_gpio_get_pdata(struct platform_device *pdev)
+{
+ struct device_node *dn = pdev->dev.of_node;
+ struct davinci_gpio_platform_data *pdata;
+ int ret;
+ u32 val;
+
+ if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
+ return pdev->dev.platform_data;
+
+ pdata = devm_kzalloc(>dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ ret = of_property_read_u32(dn, "ti,ngpio", );
+ if (ret)
+ goto of_err;
+
+ pdata->ngpio = val;
+
+ ret = of_property_read_u32(dn, "ti,davinci-gpio-unbanked", );
+ if (ret)
+ goto of_err;
+
+ pdata->gpio_unbanked = val;
+
+ return pdata;
+
+of_err:
+ dev_err(>dev, "Populating pdata from DT failed: err %d\n", ret);
+ return NULL;
+}
+
static int davinci_gpio_probe(struct platform_device *pdev)
{
int i, base;
@@ -144,12 +181,14 @@ static int davinci_gpio_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct resource *res;
- pdata = dev->platform_data;
+ pdata = davinci_gpio_get_pdata(pdev);
if (!pdata) {
dev_err(dev, "No platform data found\n");
return -EINVAL;
}
+ dev->platform_data = pdata;
+
/*
* The gpio banks conceptually expose a segmented bitmap,
* and "ngpio" is one more than the largest zero-based
@@ -501,11 +540,20 @@ done:
return 0;
}
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id davinci_gpio_ids[] = {
+ { .compatible = "ti,dm6441-gpio", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, davinci_gpio_ids);
+#endif
+
static struct
Re: linux-next: Tree for Nov 1 (xen_swiotllb)
On Fri, 1 Nov 2013, Konrad Rzeszutek Wilk wrote: > On Fri, Nov 01, 2013 at 11:16:26AM -0700, Randy Dunlap wrote: > > On 11/01/13 01:11, Stephen Rothwell wrote: > > > Hi all, > > > > > > Changes since 20131031: > > > > > > The squashfs tree gained a build failure so I used the version from > > > next-20131031. > > > > > > The block tree gained conflicts against the f2fs, aio-direct and Linus' > > > trees and a build failure and generated several warnings so I used the > > > version from next-20131031. > > > > > > The dt-rh tree gained a conflict against the powerpc tree. > > > > > > The kvm-ppc tree gained a conflict against the powerpc tree. > > > > > > The leds tree gained a conflict against the powerpc tree. > > > > > > The tty tree lost its build failure. > > > > > > on x86_64, when CONFIG_PCI is not enabled: > > > > arch/x86/built-in.o: In function `pci_xen_swiotlb_init_late': > > (.text+0x102cc): undefined reference to `pci_request_acs' > > arch/x86/built-in.o: In function `pci_xen_swiotlb_init': > > (.init.text+0x3f6c): undefined reference to `pci_request_acs' > > Stefano, > > Please fix that. I think it is commit 83862ccfc0a03212fde43b4ac29c28381828768b > Author: Stefano Stabellini > Date: Thu Oct 10 13:40:44 2013 + > > xen/arm,arm64: enable SWIOTLB_XEN > > that is causing this. Is it safe to add: > >depends on PCI > > back on it? On ARM it is possible to use the swiotlb without PCI support. Ideally we wouldn't even build arch/x86/xen/pci-swiotlb-xen.c if CONFIG_PCI was missing. However other core x86 kernel stuff seem to have similar issues, for example arch/x86/kernel/pci-swiotlb.c build with or without CONFIG_PCI and references pci_xen_swiotlb_detect. I think that the right solution would be to completely disentangle CONFIG_PCI from swiotlb related stuff, but for the moment I went for the easy fix: commit 1e6d541cc26683d0f347e1cedfee1bc57e3f8875 Author: Stefano Stabellini Date: Mon Nov 4 18:11:54 2013 + pci-swiotlb-xen: call pci_request_acs only ifdef CONFIG_PCI Signed-off-by: Stefano Stabellini diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c index 9695704..0e98e5d 100644 --- a/arch/x86/xen/pci-swiotlb-xen.c +++ b/arch/x86/xen/pci-swiotlb-xen.c @@ -75,8 +75,10 @@ void __init pci_xen_swiotlb_init(void) xen_swiotlb_init(1, true /* early */); dma_ops = _swiotlb_dma_ops; +#ifdef CONFIG_PCI /* Make sure ACS will be enabled */ pci_request_acs(); +#endif } } @@ -92,8 +94,10 @@ int pci_xen_swiotlb_init_late(void) return rc; dma_ops = _swiotlb_dma_ops; +#ifdef CONFIG_PCI /* Make sure ACS will be enabled */ pci_request_acs(); +#endif return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 30 (include/xen/swiotlb-xen.h)
On Mon, Nov 04, 2013 at 06:14:26PM +, Stefano Stabellini wrote: > On Fri, 1 Nov 2013, Konrad Rzeszutek Wilk wrote: > > On Wed, Oct 30, 2013 at 11:44:51AM -0700, Randy Dunlap wrote: > > > On 10/30/13 00:45, Stephen Rothwell wrote: > > > > Hi all, > > > > > > > > News: I am now doing an arm multi_v7_defconfig build between each > > > > merge. > > > > > > > > Changes since 20131029: > > > > > > > > The arm defconfig build is fixed again. > > > > > > > > The net-next tree gained a conflict against the net tree. > > > > > > > > The xen-tip tree gained a conflict against the arm tree. > > > > > > > > The akpm-current tree gained a conflict against the tip tree and a build > > > > failure for which I reverted 3 commits. > > > > > > > > Various build problems from yesterday have been resolved. > > > > > > on x86_64: > > > > Stefano, please fix that. > > Thanks for the notification. I am appending the fix that I am about to > apply to xentip/linux-next. > Acked-by: Konrad Rzeszutek Wilk > > commit bb5ebdb6a674c59cd7b5d159d6ca3c0084ee60e1 > Author: Stefano Stabellini > Date: Mon Nov 4 17:54:27 2013 + > > swiotlb-xen: missing include dma-direction.h > > Signed-off-by: Stefano Stabellini > > diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h > index 7b64465..8b2eb93 100644 > --- a/include/xen/swiotlb-xen.h > +++ b/include/xen/swiotlb-xen.h > @@ -1,6 +1,7 @@ > #ifndef __LINUX_SWIOTLB_XEN_H > #define __LINUX_SWIOTLB_XEN_H > > +#include > #include > > extern int xen_swiotlb_init(int verbose, bool early); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Nov 1 (xen_swiotllb)
On Mon, Nov 04, 2013 at 06:20:42PM +, Stefano Stabellini wrote: > On Fri, 1 Nov 2013, Konrad Rzeszutek Wilk wrote: > > On Fri, Nov 01, 2013 at 11:16:26AM -0700, Randy Dunlap wrote: > > > On 11/01/13 01:11, Stephen Rothwell wrote: > > > > Hi all, > > > > > > > > Changes since 20131031: > > > > > > > > The squashfs tree gained a build failure so I used the version from > > > > next-20131031. > > > > > > > > The block tree gained conflicts against the f2fs, aio-direct and Linus' > > > > trees and a build failure and generated several warnings so I used the > > > > version from next-20131031. > > > > > > > > The dt-rh tree gained a conflict against the powerpc tree. > > > > > > > > The kvm-ppc tree gained a conflict against the powerpc tree. > > > > > > > > The leds tree gained a conflict against the powerpc tree. > > > > > > > > The tty tree lost its build failure. > > > > > > > > > on x86_64, when CONFIG_PCI is not enabled: > > > > > > arch/x86/built-in.o: In function `pci_xen_swiotlb_init_late': > > > (.text+0x102cc): undefined reference to `pci_request_acs' > > > arch/x86/built-in.o: In function `pci_xen_swiotlb_init': > > > (.init.text+0x3f6c): undefined reference to `pci_request_acs' > > > > Stefano, > > > > Please fix that. I think it is commit > > 83862ccfc0a03212fde43b4ac29c28381828768b > > Author: Stefano Stabellini > > Date: Thu Oct 10 13:40:44 2013 + > > > > xen/arm,arm64: enable SWIOTLB_XEN > > > > that is causing this. Is it safe to add: > > > >depends on PCI > > > > back on it? > > On ARM it is possible to use the swiotlb without PCI support. > Ideally we wouldn't even build arch/x86/xen/pci-swiotlb-xen.c if > CONFIG_PCI was missing. However other core x86 kernel stuff seem to have > similar issues, for example arch/x86/kernel/pci-swiotlb.c build with or > without CONFIG_PCI and references pci_xen_swiotlb_detect. > I think that the right solution would be to completely disentangle > CONFIG_PCI from swiotlb related stuff, but for the moment I went for the > easy fix: Acked-by: Konrad Rzeszutek Wilk > > > commit 1e6d541cc26683d0f347e1cedfee1bc57e3f8875 > Author: Stefano Stabellini > Date: Mon Nov 4 18:11:54 2013 + > > pci-swiotlb-xen: call pci_request_acs only ifdef CONFIG_PCI > > Signed-off-by: Stefano Stabellini > > diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c > index 9695704..0e98e5d 100644 > --- a/arch/x86/xen/pci-swiotlb-xen.c > +++ b/arch/x86/xen/pci-swiotlb-xen.c > @@ -75,8 +75,10 @@ void __init pci_xen_swiotlb_init(void) > xen_swiotlb_init(1, true /* early */); > dma_ops = _swiotlb_dma_ops; > > +#ifdef CONFIG_PCI > /* Make sure ACS will be enabled */ > pci_request_acs(); > +#endif > } > } > > @@ -92,8 +94,10 @@ int pci_xen_swiotlb_init_late(void) > return rc; > > dma_ops = _swiotlb_dma_ops; > +#ifdef CONFIG_PCI > /* Make sure ACS will be enabled */ > pci_request_acs(); > +#endif > > return 0; > } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] KEYS: Implement keyctl control for encrypted keys
Implement "keyctl control" for encrypted keys rather than trying to do this
with the update method (which won't function correctly when add_key() tries to
update an existing key).
Provide a command to change the master key:
keyctl control "encrypted change-master-key "
Signed-off-by: David Howells
---
security/keys/encrypted-keys/encrypted.c | 56 ++
1 file changed, 56 insertions(+)
diff --git a/security/keys/encrypted-keys/encrypted.c
b/security/keys/encrypted-keys/encrypted.c
index 9e1e005c7596..f9e7b808fa47 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -884,6 +884,61 @@ out:
}
/*
+ * encrypted_control - control an encrypted key in a type-specific way
+ */
+static long encrypted_control(struct key *key, char *command,
+ char *reply, size_t reply_size)
+{
+ static const char expected_command[] = "encrypted change-master-key ";
+ struct encrypted_key_payload *epayload, *new_epayload;
+ char *new_master_desc = NULL;
+ const char *format = NULL;
+ size_t datalen;
+ int ret;
+
+ if (memcmp(command, expected_command, sizeof(expected_command) - 1) !=
0)
+ return -EINVAL;
+ command += sizeof(expected_command) - 1;
+ datalen = strlen(command);
+
+ if (datalen <= 0 || datalen > 32767)
+ return -EINVAL;
+
+ ret = datablob_parse(command, , _master_desc, NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ down_write(>sem);
+ epayload = rcu_dereference_protected(key->payload.rcudata, >sem);
+
+ ret = valid_master_desc(new_master_desc, epayload->master_desc);
+ if (ret < 0) {
+ up_write(>sem);
+ return ret;
+ }
+
+ new_epayload = encrypted_key_alloc(key, epayload->format,
+ new_master_desc, epayload->datalen);
+ if (IS_ERR(new_epayload)) {
+ up_write(>sem);
+ return PTR_ERR(new_epayload);
+ }
+
+ __ekey_init(new_epayload, epayload->format, new_master_desc,
+ epayload->datalen);
+
+ memcpy(new_epayload->iv, epayload->iv, ivsize);
+ memcpy(new_epayload->payload_data, epayload->payload_data,
+ epayload->payload_datalen);
+
+ rcu_assign_keypointer(key, new_epayload);
+
+ up_write(>sem);
+ call_rcu(>rcu, encrypted_rcu_free);
+ return 0;
+}
+
+/*
* encrypted_read - format and copy the encrypted data to userspace
*
* The resulting datablob format is:
@@ -974,6 +1029,7 @@ struct key_type key_type_encrypted = {
.destroy = encrypted_destroy,
.describe = user_describe,
.read = encrypted_read,
+ .control = encrypted_control,
};
EXPORT_SYMBOL_GPL(key_type_encrypted);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] KEYS: Allow expiry time to be set when preparsing a key
Allow a key type's preparsing routine to set the expiry time for a key.
Signed-off-by: David Howells
---
Documentation/security/keys.txt | 10 +++---
include/linux/key-type.h|1 +
security/keys/key.c |8
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
index a4c33f1a7c6d..315cf96a41a2 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys.txt
@@ -1150,20 +1150,24 @@ The structure has a number of fields, some of which are
mandatory:
const void *data;
size_t datalen;
size_t quotalen;
+ time_t expiry;
};
Before calling the method, the caller will fill in data and datalen with
the payload blob parameters; quotalen will be filled in with the default
- quota size from the key type and the rest will be cleared.
+ quota size from the key type; expiry will be set to TIME_T_MAX and the
+ rest will be cleared.
If a description can be proposed from the payload contents, that should be
attached as a string to the description field. This will be used for the
key description if the caller of add_key() passes NULL or "".
The method can attach anything it likes to type_data[] and payload. These
- are merely passed along to the instantiate() or update() operations.
+ are merely passed along to the instantiate() or update() operations. If
+ set, the expiry time will be applied to the key if it is instantiated from
+ this data.
- The method should return 0 if success ful or a negative error code
+ The method should return 0 if successful or a negative error code
otherwise.
diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index d2b4845d74bf..44792ee649de 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -45,6 +45,7 @@ struct key_preparsed_payload {
const void *data; /* Raw data */
size_t datalen;/* Raw datalen */
size_t quotalen; /* Quota length for proposed payload */
+ time_t expiry; /* Expiry time of key */
booltrusted;/* True if key is trusted */
};
diff --git a/security/keys/key.c b/security/keys/key.c
index 64dc9cf6848e..1af0edacd804 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -443,6 +443,11 @@ static int __key_instantiate_and_link(struct key *key,
/* disable the authorisation key */
if (authkey)
key_revoke(authkey);
+
+ if (prep->expiry != TIME_T_MAX) {
+ key->expiry = prep->expiry;
+ key_schedule_gc(prep->expiry + key_gc_delay);
+ }
}
}
@@ -485,6 +490,7 @@ int key_instantiate_and_link(struct key *key,
prep.data = data;
prep.datalen = datalen;
prep.quotalen = key->type->def_datalen;
+ prep.expiry = TIME_T_MAX;
if (key->type->preparse) {
ret = key->type->preparse();
if (ret < 0)
@@ -817,6 +823,7 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
prep.datalen = plen;
prep.quotalen = index_key.type->def_datalen;
prep.trusted = flags & KEY_ALLOC_TRUSTED;
+ prep.expiry = TIME_T_MAX;
if (index_key.type->preparse) {
ret = index_key.type->preparse();
if (ret < 0) {
@@ -947,6 +954,7 @@ int key_update(key_ref_t key_ref, const void *payload,
size_t plen)
prep.data = payload;
prep.datalen = plen;
prep.quotalen = key->type->def_datalen;
+ prep.expiry = TIME_T_MAX;
if (key->type->preparse) {
ret = key->type->preparse();
if (ret < 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: use generic RW_DATA_SECTION macro in linker script
On Mon, Nov 04, 2013 at 04:38:47PM +, Mark Salter wrote: > The .data section in the arm64 linker script currently lacks a > definition for page-aligned data. This leads to a .page_aligned > section being placed between the end of data and start of bss. > This patch corrects that by using the generic RW_DATA_SECTION > macro which includes support for page-aligned data. > > Signed-off-by: Mark Salter Thanks. Applied. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 30 (include/xen/swiotlb-xen.h)
On Fri, 1 Nov 2013, Konrad Rzeszutek Wilk wrote: > On Wed, Oct 30, 2013 at 11:44:51AM -0700, Randy Dunlap wrote: > > On 10/30/13 00:45, Stephen Rothwell wrote: > > > Hi all, > > > > > > News: I am now doing an arm multi_v7_defconfig build between each merge. > > > > > > Changes since 20131029: > > > > > > The arm defconfig build is fixed again. > > > > > > The net-next tree gained a conflict against the net tree. > > > > > > The xen-tip tree gained a conflict against the arm tree. > > > > > > The akpm-current tree gained a conflict against the tip tree and a build > > > failure for which I reverted 3 commits. > > > > > > Various build problems from yesterday have been resolved. > > > > on x86_64: > > Stefano, please fix that. Thanks for the notification. I am appending the fix that I am about to apply to xentip/linux-next. commit bb5ebdb6a674c59cd7b5d159d6ca3c0084ee60e1 Author: Stefano Stabellini Date: Mon Nov 4 17:54:27 2013 + swiotlb-xen: missing include dma-direction.h Signed-off-by: Stefano Stabellini diff --git a/include/xen/swiotlb-xen.h b/include/xen/swiotlb-xen.h index 7b64465..8b2eb93 100644 --- a/include/xen/swiotlb-xen.h +++ b/include/xen/swiotlb-xen.h @@ -1,6 +1,7 @@ #ifndef __LINUX_SWIOTLB_XEN_H #define __LINUX_SWIOTLB_XEN_H +#include #include extern int xen_swiotlb_init(int verbose, bool early); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH 0/9] encrypted keys & key control op
Hi Mimi, Dmitry, Here's a series of patches, the last three of which attempt to fix up a problem with encrypted keys update method. The preceding patches are fixes or are preparatory for other changes that I want to put underneath. I really want to make all key types use ->preparse() to avoid a deadlock in the garbage collector with quota recycling, but encrypted_update() requires access to the old key - which you can't have in ->preparse() because the keyring isn't locked (and this lock is the root of the gc deadlock anyway). Further, the existence of encrypted_update() means that add_key() will sometimes get things wrong with encrypted keys (add_key() will call ->update() if a matching key already exists rather than creating a new key). But you can't pre-search for the existence of a key and mould the payload accordingly because that means you can race against both add_key() and keyctl_unlink(). My solution is to add a new keyctl function that allows the caller to perform a type-specific operation on a key: long keyctl_control(key_serial_t key_id, const char *command, char *reply_buffer, size_t reply_size); This would then take a NUL-terminated string indicating the command and arguments and potentially return a reply up to the buffer length. For instance: keyctl_control(1234, "encrypted change-master-key fred's key", NULL, 0); or, from the shell: keyctl control 1234 "encrypted change-master-key fred's key" (I think that requiring the command string to be prefixed with the expected key type is probably a good idea). The control op could also be used for other things like pushing a key into a TPM. What do you think? David --- David Howells (9): KEYS: The RSA public key algorithm needs to select MPILIB KEYS: Provide a generic instantiation function KEYS: struct key_preparsed_payload should have two payload pointers KEYS: Allow expiry time to be set when preparsing a key KEYS: Call ->free_preparse() even after ->preparse() returns an error KEYS: Trusted: Use key preparsing KEYS: Add a keyctl function to alter/control a key in type-dependent way KEYS: Implement keyctl control for encrypted keys KEYS: Fix encrypted key type update method Documentation/security/keys.txt | 48 +++- crypto/asymmetric_keys/Kconfig |1 crypto/asymmetric_keys/asymmetric_type.c | 27 crypto/asymmetric_keys/x509_public_key.c |2 include/linux/key-type.h | 11 ++ include/uapi/linux/keyctl.h |1 security/keys/compat.c |6 + security/keys/encrypted-keys/encrypted.c | 111 +- security/keys/internal.h |2 security/keys/key.c | 49 +++- security/keys/keyctl.c | 104 security/keys/trusted.c | 190 ++ 12 files changed, 385 insertions(+), 167 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cache largest vma
On Mon, Nov 04, 2013 at 06:52:45PM +0100, Ingo Molnar wrote: > > * Frederic Weisbecker wrote: > > > On Mon, Nov 04, 2013 at 08:05:00AM +0100, Ingo Molnar wrote: > > > > > > * Davidlohr Bueso wrote: > > > > > > > Btw, do you suggest using a high level tool such as perf for getting > > > > this data or sprinkling get_cycles() in find_vma() -- I'd think that > > > > the > > > > first isn't fine grained enough, while the later will probably variate > > > > a > > > > lot from run to run but the ratio should be rather constant. > > > > > > LOL - I guess I should have read your mail before replying to it ;-) > > > > > > Yes, I think get_cycles() works better in this case - not due to > > > granularity (perf stat will report cycle granular just fine), but due > > > to the size of the critical path you'll be measuring. You really want > > > to extract the delta, because it's probably so much smaller than the > > > overhead of the workload itself. > > > > > > [ We still don't have good 'measure overhead from instruction X to > > > instruction Y' delta measurement infrastructure in perf yet, > > > although Frederic is working on such a trigger/delta facility AFAIK. > > > ] > > > > Yep, in fact Jiri took it over and he's still working on it. But yeah, > > once that get merged, we should be able to measure instructions or > > cycles inside any user or kernel function through kprobes/uprobes or > > function graph tracer. > > So, what would be nice is to actually make use of it: one very nice > usecase I'd love to see is to have the capability within the 'perf top' > TUI annotated assembly output to mark specific instructions as 'start' and > 'end' markers, and measure the overhead between them. Yeah that would be a nice interface. Speaking about that, it would be nice to get your input on the proposed interface for toggle events. It's still in an RFC state, although it's getting quite elaborated, and I believe we haven't yet found a real direction to take for the tooling interface IIRC. For example the perf record cmdline used to state toggle events based contexts was one of the parts we were not that confident about. And we really don't want to take a wrong direction for that as it's going to be complicated to handle in any case. See this thread: https://lwn.net/Articles/568602/ thanks. > > I.e. allow perf top / perf report to manage probes into interesting > functions - or create a similar TUI for 'perf probe' to allow easy live > marking/probing of various kernel functionality. > > Thanks, > > Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/29] perf tools: Add time argument on COMM setting
From: Frederic Weisbecker
This way we can later delimit a lifecycle for the COMM and map a hist to
a precise COMM:timeslice couple.
PERF_RECORD_COMM and PERF_RECORD_FORK events that don't have
PERF_SAMPLE_TIME samples can only send 0 value as a timestamp and thus
should overwrite any previous COMM on a given thread because there is no
sensible way to keep track of all the comms lifecycles in a thread
without time informations.
Signed-off-by: Frederic Weisbecker
Tested-by: Jiri Olsa
Cc: Jiri Olsa
Cc: David Ahern
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-6tyow99vgmmtt9qwr2u2l...@git.kernel.org
[ Made it cope with PERF_RECORD_MMAP2 ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-top.c| 2 +-
tools/perf/builtin-trace.c | 12 ++--
tools/perf/tests/code-reading.c | 2 +-
tools/perf/tests/hists_link.c | 4 ++--
tools/perf/util/event.c | 28 ++--
tools/perf/util/machine.c | 39 ++-
tools/perf/util/machine.h | 21 ++---
tools/perf/util/session.c | 2 +-
tools/perf/util/thread.c| 6 --
tools/perf/util/thread.h| 4 ++--
10 files changed, 67 insertions(+), 53 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index a6ea956a533e..21db76d71ddf 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -856,7 +856,7 @@ static void perf_top__mmap_read_idx(struct perf_top *top,
int idx)
, machine);
} else if (event->header.type < PERF_RECORD_MAX) {
hists__inc_nr_events(>hists, event->header.type);
- machine__process_event(machine, event);
+ machine__process_event(machine, event, );
} else
++session->stats.nr_unknown_events;
next_event:
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index dc3da654ff12..95d639212d98 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1122,7 +1122,7 @@ static size_t trace__fprintf_entry_head(struct trace
*trace, struct thread *thre
}
static int trace__process_event(struct trace *trace, struct machine *machine,
- union perf_event *event)
+ union perf_event *event, struct perf_sample
*sample)
{
int ret = 0;
@@ -1130,9 +1130,9 @@ static int trace__process_event(struct trace *trace,
struct machine *machine,
case PERF_RECORD_LOST:
color_fprintf(trace->output, PERF_COLOR_RED,
"LOST %" PRIu64 " events!\n", event->lost.lost);
- ret = machine__process_lost_event(machine, event);
+ ret = machine__process_lost_event(machine, event, sample);
default:
- ret = machine__process_event(machine, event);
+ ret = machine__process_event(machine, event, sample);
break;
}
@@ -1141,11 +1141,11 @@ static int trace__process_event(struct trace *trace,
struct machine *machine,
static int trace__tool_process(struct perf_tool *tool,
union perf_event *event,
- struct perf_sample *sample __maybe_unused,
+ struct perf_sample *sample,
struct machine *machine)
{
struct trace *trace = container_of(tool, struct trace, tool);
- return trace__process_event(trace, machine, event);
+ return trace__process_event(trace, machine, event, sample);
}
static int trace__symbols_init(struct trace *trace, struct perf_evlist *evlist)
@@ -1751,7 +1751,7 @@ again:
trace->base_time = sample.time;
if (type != PERF_RECORD_SAMPLE) {
- trace__process_event(trace, trace->host, event);
+ trace__process_event(trace, trace->host, event,
);
continue;
}
diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index e3fedfa2906e..49ccc3b2995e 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -276,7 +276,7 @@ static int process_event(struct machine *machine, struct
perf_evlist *evlist,
return process_sample_event(machine, evlist, event, state);
if (event->header.type < PERF_RECORD_MAX)
- return machine__process_event(machine, event);
+ return machine__process_event(machine, event, NULL);
return 0;
}
diff --git a/tools/perf/tests/hists_link.c b/tools/perf/tests/hists_link.c
index 4475b0ff76e5..6c337e653540 100644
--- a/tools/perf/tests/hists_link.c
+++ b/tools/perf/tests/hists_link.c
@@ -93,7
[PATCH 06/29] perf tools: Compare hists comm by addresses
From: Frederic Weisbecker
Now that comm strings are allocated only once and refcounted to be shared
among threads, these can now be safely compared by addresses. This
should remove most hists collapses on post processing.
Signed-off-by: Frederic Weisbecker
Tested-by: Jiri Olsa
Cc: Jiri Olsa
Cc: David Ahern
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1381468543-25334-8-git-send-email-namhy...@kernel.org
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 835e8bdd869f..bf91d0e5c16e 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -80,7 +80,8 @@ struct sort_entry sort_thread = {
static int64_t
sort__comm_cmp(struct hist_entry *left, struct hist_entry *right)
{
- return right->thread->tid - left->thread->tid;
+ /* Compare the addr that should be unique among comm */
+ return thread__comm_str(right->thread) - thread__comm_str(left->thread);
}
static int64_t
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 25/29] tools lib traceevent: Handle __print_hex(__get_dynamic_array(fieldname), len)
From: Howard Cochran
The kernel has a few events with a format similar to this excerpt:
field:unsigned int len; offset:12; size:4; signed:0;
field:__data_loc unsigned char[] data_array; offset:16; size:4;
signed:0;
print fmt: "%s", __print_hex(__get_dynamic_array(data_array), REC->len)
trace-cmd could already parse that arg correctly, but print_str_arg()
was unable to handle the first parameter being a dynamic array. (It
just printed a "field not found" warning).
Teach print_str_arg's PRINT_HEX case to handle the nested
PRINT_DYNAMIC_ARRAY correctly. The output now matches the kernel's own
formatting for this case.
Signed-off-by: Howard Cochran
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1381503349-12271-1-git-send-email-hcoch...@lexmark.com
[ Removed "polish compare", we don't do that here ]
Signed-off-by: Steven Rostedt
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 013c8d3db806..0a1ffe07de3f 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3588,15 +3588,23 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
}
break;
case PRINT_HEX:
- field = arg->hex.field->field.field;
- if (!field) {
- str = arg->hex.field->field.name;
- field = pevent_find_any_field(event, str);
- if (!field)
- goto out_warning_field;
- arg->hex.field->field.field = field;
+ if (arg->hex.field->type == PRINT_DYNAMIC_ARRAY) {
+ unsigned long offset;
+ offset = pevent_read_number(pevent,
+ data + arg->hex.field->dynarray.field->offset,
+ arg->hex.field->dynarray.field->size);
+ hex = data + (offset & 0x);
+ } else {
+ field = arg->hex.field->field.field;
+ if (!field) {
+ str = arg->hex.field->field.name;
+ field = pevent_find_any_field(event, str);
+ if (!field)
+ goto out_warning_field;
+ arg->hex.field->field.field = field;
+ }
+ hex = data + field->offset;
}
- hex = data + field->offset;
len = eval_num_arg(data, size, event, arg->hex.size);
for (i = 0; i < len; i++) {
if (i)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/29] perf tools: Add new COMM infrastructure
From: Frederic Weisbecker
This new COMM infrastructure provides two features:
1) It keeps track of all comms lifecycle for a given thread. This way we
can associate a timeframe to any thread COMM, as long as
PERF_SAMPLE_TIME samples are joined to COMM and fork events.
As a result we should have more precise COMM sorted hists with seperated
entries for pre and post exec time after a fork.
2) It also makes sure that a given COMM string is not duplicated but
rather shared among the threads that refer to it. This way the threads
COMM can be compared against pointer values from the sort
infrastructure.
Signed-off-by: Frederic Weisbecker
Tested-by: Jiri Olsa
Cc: Jiri Olsa
Cc: David Ahern
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-hwjf70b2wve9m2kosxiq8...@git.kernel.org
[ Rename some accessor functions ]
Signed-off-by: Namhyung Kim
[ Use __ as separator for class__method for private comm_str methods ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Makefile.perf | 2 +
tools/perf/builtin-trace.c | 4 +-
tools/perf/util/comm.c | 106 +
tools/perf/util/comm.h | 20 +
tools/perf/util/thread.c | 92 +--
tools/perf/util/thread.h | 3 +-
6 files changed, 200 insertions(+), 27 deletions(-)
create mode 100644 tools/perf/util/comm.c
create mode 100644 tools/perf/util/comm.h
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index bc7cfa18a1e3..cb52bdb755c7 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -273,6 +273,7 @@ LIB_H += util/color.h
LIB_H += util/values.h
LIB_H += util/sort.h
LIB_H += util/hist.h
+LIB_H += util/comm.h
LIB_H += util/thread.h
LIB_H += util/thread_map.h
LIB_H += util/trace-event.h
@@ -341,6 +342,7 @@ LIB_OBJS += $(OUTPUT)util/machine.o
LIB_OBJS += $(OUTPUT)util/map.o
LIB_OBJS += $(OUTPUT)util/pstack.o
LIB_OBJS += $(OUTPUT)util/session.o
+LIB_OBJS += $(OUTPUT)util/comm.o
LIB_OBJS += $(OUTPUT)util/thread.o
LIB_OBJS += $(OUTPUT)util/thread_map.o
LIB_OBJS += $(OUTPUT)util/trace-event-parse.o
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 95d639212d98..b3e57dc64546 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1114,7 +1114,7 @@ static size_t trace__fprintf_entry_head(struct trace
*trace, struct thread *thre
if (trace->multiple_threads) {
if (trace->show_comm)
- printed += fprintf(fp, "%.14s/", thread->comm);
+ printed += fprintf(fp, "%.14s/",
thread__comm_str(thread));
printed += fprintf(fp, "%d ", thread->tid);
}
@@ -1986,7 +1986,7 @@ static int trace__fprintf_one_thread(struct thread
*thread, void *priv)
else if (ratio > 5.0)
color = PERF_COLOR_YELLOW;
- printed += color_fprintf(fp, color, "%20s", thread->comm);
+ printed += color_fprintf(fp, color, "%20s", thread__comm_str(thread));
printed += fprintf(fp, " - %-5d :%11lu [", thread->tid,
ttrace->nr_events);
printed += color_fprintf(fp, color, "%5.1f%%", ratio);
printed += fprintf(fp, " ] %10.3f ms\n", ttrace->runtime_ms);
diff --git a/tools/perf/util/comm.c b/tools/perf/util/comm.c
new file mode 100644
index ..8b3ac9f0207f
--- /dev/null
+++ b/tools/perf/util/comm.c
@@ -0,0 +1,106 @@
+#include "comm.h"
+#include "util.h"
+#include
+#include
+
+struct comm_str {
+ char *str;
+ struct rb_node rb_node;
+ int ref;
+};
+
+/* Should perhaps be moved to struct machine */
+static struct rb_root comm_str_root;
+
+static void comm_str__get(struct comm_str *cs)
+{
+ cs->ref++;
+}
+
+static void comm_str__put(struct comm_str *cs)
+{
+ if (!--cs->ref) {
+ rb_erase(>rb_node, _str_root);
+ free(cs->str);
+ free(cs);
+ }
+}
+
+static struct comm_str *comm_str__alloc(const char *str)
+{
+ struct comm_str *cs;
+
+ cs = zalloc(sizeof(*cs));
+ if (!cs)
+ return NULL;
+
+ cs->str = strdup(str);
+ if (!cs->str) {
+ free(cs);
+ return NULL;
+ }
+
+ return cs;
+}
+
+static struct comm_str *comm_str__findnew(const char *str, struct rb_root
*root)
+{
+ struct rb_node **p = >rb_node;
+ struct rb_node *parent = NULL;
+ struct comm_str *iter, *new;
+ int cmp;
+
+ while (*p != NULL) {
+ parent = *p;
+ iter = rb_entry(parent, struct comm_str, rb_node);
+
+ cmp = strcmp(str, iter->str);
+ if (!cmp)
+ return iter;
+
+ if (cmp < 0)
+ p = &(*p)->rb_left;
+ else
+ p = &(*p)->rb_right;
+ }
+
+ new = comm_str__alloc(str);
+ if (!new)
+
[PATCH 7/9] KEYS: Add a keyctl function to alter/control a key in type-dependent way
Add a function to permit a key to be altered or controlled in a type-dependent
way. This is given text strings as its command and argument parameters and is
permitted to return a string to a maximum buffer size (including NUL):
long keyctl_control(key_serial_t keyid,
const char *command,
char *reply_buffer,
size_t reply_size);
The caller must have WRITE permission on a key to be able to perform this
function. The type is not required to implement this, but if it does, it must
perform its own locking against other 'writes' using the key semaphore.
The command string must begin with the type name and a space so that the method
can check that the command is from its expected set (it is permitted, however,
to honour commands from another type's set). This should be followed by the
command name and then, optionally, another space and whatever arguments are
required. The command can be up to 1MB in size including the NUL terminator.
The reply buffer is optional and can be up to 1MB in size. The actual size of
the reply will be returned and, if necessary, the reply will be truncated to
reply_size.
This can be invoked from the keyctl command in userspace. One example would be
to use this to change the master key used by an encrypted key:
keyctl control 1234 "encrypted change-master-key 6789"
Signed-off-by: David Howells
---
Documentation/security/keys.txt | 34 +
include/linux/key-type.h|6 ++
include/uapi/linux/keyctl.h |1
security/keys/compat.c |6 ++
security/keys/internal.h|2 +
security/keys/keyctl.c | 104 +++
6 files changed, 153 insertions(+)
diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
index 3bbec087fc5f..a5792bcb64b2 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys.txt
@@ -1331,6 +1331,40 @@ The structure has a number of fields, some of which are
mandatory:
The authorisation key.
+ (*) long (*control)(struct key *key, char *command, char *reply,
+size_t reply_size);
+
+ This method is optional. If provided, keyctl_control() can be invoked
+ from userspace to perform some type-specific operation upon the key. If
+ the method is not implemented then error EOPNOTSUPP will be returned.
+
+ The method must provide its own locking against other 'writes' using the
+ key semaphore.
+
+ The command argument will point to a NUL-terminated string up to 1MB in
+ size, including the NUL terminator. The method may modify the command
+ buffer (eg. with strsep()).
+
+ The command should begin with the type name and a space so that the method
+ can check that the command is from its expected set. It is permitted,
+ however, to honour commands from another type's set. This should be
+ followed by the command name and then, optionally, another space and
+ whatever arguments are required.
+
+ The reply buffer will be NULL if userspace didn't ask for a reply.
+ Otherwise it will be a kernel-space buffer the size of which was specified
+ by userspace (max 1MB). The actual size of the reply should be returned
+ (and can be larger than reply_size). The caller will copy back the
+ contents of the reply buffer up to reply_size.
+
+ An example might be:
+
+ encrypted change-master-key
+
+ The return value is the reply size, 0 (if no reply) or a negative error
+ code.
+
+
REQUEST-KEY CALLBACK SERVICE
diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index 44792ee649de..610669c780f7 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -129,6 +129,12 @@ struct key_type {
*/
request_key_actor_t request_key;
+ /* Control or alter a key (optional)
+* - The command string can be modified (eg. with strsep()).
+*/
+ long (*control)(struct key *key, char *command,
+ char *reply, size_t reply_size);
+
/* internal fields */
struct list_headlink; /* link in types list */
struct lock_class_key lock_class; /* key->sem lock class */
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 840cb990abe2..9687b9c726b2 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -57,5 +57,6 @@
#define KEYCTL_INSTANTIATE_IOV 20 /* instantiate a partially
constructed key */
#define KEYCTL_INVALIDATE 21 /* invalidate a key */
#define KEYCTL_GET_PERSISTENT 22 /* get a user's persistent
keyring */
+#define KEYCTL_CONTROL 23 /* control/alter a key */
#endif /* _LINUX_KEYCTL_H */
diff --git a/security/keys/compat.c
[PATCH 19/29] perf report: Use parse_options_usage() for -s option failure
From: Namhyung Kim
The -s (--sort) option was processed after normal option parsing so that
it cannot call the parse_options_usage() automatically. Currently it
calls usage_with_options() which shows entire help messages for event
option. Fix it by showing just -s options.
$ perf report -s help
Error: Unknown --sort key: `help'
usage: perf report []
-s, --sort
sort by key(s): pid, comm, dso, symbol, ...
Signed-off-by: Namhyung Kim
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-4-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4df3161c7df2..25f83d5d66fd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -947,8 +947,10 @@ repeat:
sort_order =
"local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked";
}
- if (setup_sorting() < 0)
- usage_with_options(report_usage, options);
+ if (setup_sorting() < 0) {
+ parse_options_usage(report_usage, options, "s", 1);
+ goto error;
+ }
if (parent_pattern != default_parent_pattern) {
if (sort_dimension__add("parent") < 0)
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 24/29] tools lib traceevent: If %s is a pointer, check printk formats
From: "Steven Rostedt (Red Hat)"
If the format string of TP_printk() contains a %s, and the argument is
not a string, check if the argument is a pointer that might match the
printk_formats that were stored.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215500.698924...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 856b79105abc..013c8d3db806 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3505,6 +3505,7 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
struct pevent *pevent = event->pevent;
struct print_flag_sym *flag;
struct format_field *field;
+ struct printk_map *printk;
unsigned long long val, fval;
unsigned long addr;
char *str;
@@ -3540,7 +3541,12 @@ static void print_str_arg(struct trace_seq *s, void
*data, int size,
if (!(field->flags & FIELD_IS_ARRAY) &&
field->size == pevent->long_size) {
addr = *(unsigned long *)(data + field->offset);
- trace_seq_printf(s, "%lx", addr);
+ /* Check if it matches a print format */
+ printk = find_printk(pevent, addr);
+ if (printk)
+ trace_seq_puts(s, printk->printk);
+ else
+ trace_seq_printf(s, "%lx", addr);
break;
}
str = malloc(len + 1);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 26/29] tools lib traceevent: Have bprintk output the same as the kernel does
From: "Steven Rostedt (Red Hat)"
The trace_bprintk() in the kernel looks like:
ring_buffer_producer_thread: Missed: 0
ring_buffer_producer_thread: Hit: 62174350
ring_buffer_producer_thread: Entries per millisec: 6296
ring_buffer_producer_thread: 158 ns per entry
ring_buffer_producer_thread: Sleeping for 10 secs
ring_buffer_producer_thread: Starting ring buffer hammer
ring_buffer_producer_thread: End ring buffer hammer
But the current output looks like this:
ring_buffer_producer_thread : Time: 9407018 (usecs)
ring_buffer_producer_thread : Overruns: 43285485
ring_buffer_producer_thread : Read: 4405365 (by events)
ring_buffer_producer_thread : Entries: 0
ring_buffer_producer_thread : Total:47690850
ring_buffer_producer_thread : Missed: 0
ring_buffer_producer_thread : Hit: 47690850
Remove the space between the function and the colon.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215501.272654...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 0a1ffe07de3f..e1c743c52834 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -3802,8 +3802,8 @@ static struct print_arg *make_bprint_args(char *fmt, void
*data, int size, struc
if (asprintf(>atom.atom, "%lld", ip) < 0)
goto out_free;
- /* skip the first "%pf : " */
- for (ptr = fmt + 6, bptr = data + field->offset;
+ /* skip the first "%pf: " */
+ for (ptr = fmt + 5, bptr = data + field->offset;
bptr < data + size && *ptr; ptr++) {
int ls = 0;
@@ -3929,12 +3929,12 @@ get_bprint_format(void *data, int size __maybe_unused,
printk = find_printk(pevent, addr);
if (!printk) {
- if (asprintf(, "%%pf : (NO FORMAT FOUND at %llx)\n",
addr) < 0)
+ if (asprintf(, "%%pf: (NO FORMAT FOUND at %llx)\n",
addr) < 0)
return NULL;
return format;
}
- if (asprintf(, "%s : %s", "%pf", printk->printk) < 0)
+ if (asprintf(, "%s: %s", "%pf", printk->printk) < 0)
return NULL;
return format;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/29] perf tools: Fix libunwind build and feature detection for 32-bit build
From: Adrian Hunter Use -lunwind-x86 instead of -lunwind-x86_64 for 32-bit build. Signed-off-by: Adrian Hunter Acked-by: Jiri Olsa Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1383313899-15987-5-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/config/Makefile| 6 -- tools/perf/config/feature-checks/Makefile | 4 ++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 2f1d7d78f744..ffb5f55c8fba 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -25,9 +25,11 @@ ifeq ($(ARCH),x86_64) RAW_ARCH := x86_64 CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT ARCH_INCLUDE = ../../arch/x86/lib/memcpy_64.S ../../arch/x86/lib/memset_64.S +LIBUNWIND_LIBS = -lunwind -lunwind-x86_64 + else +LIBUNWIND_LIBS = -lunwind -lunwind-x86 endif NO_PERF_REGS := 0 - LIBUNWIND_LIBS = -lunwind -lunwind-x86_64 endif ifeq ($(NO_PERF_REGS),0) @@ -96,7 +98,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) LIBUNWIND_LIBS="$(LIBUNWIND_LIBS)" -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index 353c00cde4d6..d37d58d273fe 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -36,7 +36,7 @@ BUILD = $(CC) $(CFLAGS) $(LDFLAGS) -o $(OUTPUT)$@ $@.c ### test-all: - $(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lunwind -lunwind-x86_64 -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl + $(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma $(LIBUNWIND_LIBS) -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl test-hello: $(BUILD) @@ -72,7 +72,7 @@ test-libnuma: $(BUILD) -lnuma test-libunwind: - $(BUILD) -lunwind -lunwind-x86_64 -lelf + $(BUILD) $(LIBUNWIND_LIBS) -lelf test-libaudit: $(BUILD) -laudit -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/29] perf tools: Get current comm instead of last one
From: Namhyung Kim
At insert time, a hist entry should reference comm at the time otherwise
it'll get the last comm anyway.
Signed-off-by: Namhyung Kim
Acked-by: Frederic Weisbecker
Tested-by: Jiri Olsa
Cc: Frederic Weisbecker
Link: http://lkml.kernel.org/n/tip-n6pykiiymtgmcjs834go2...@git.kernel.org
[ Fixed up const pointer issues ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/comm.c | 15 +++
tools/perf/util/comm.h | 1 +
tools/perf/util/hist.c | 3 +++
tools/perf/util/sort.c | 14 +-
tools/perf/util/sort.h | 1 +
tools/perf/util/thread.c | 6 +++---
tools/perf/util/thread.h | 2 ++
7 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/tools/perf/util/comm.c b/tools/perf/util/comm.c
index 8b3ac9f0207f..ee0df0e24cdb 100644
--- a/tools/perf/util/comm.c
+++ b/tools/perf/util/comm.c
@@ -94,6 +94,21 @@ struct comm *comm__new(const char *str, u64 timestamp)
return comm;
}
+void comm__override(struct comm *comm, const char *str, u64 timestamp)
+{
+ struct comm_str *old = comm->comm_str;
+
+ comm->comm_str = comm_str__findnew(str, _str_root);
+ if (!comm->comm_str) {
+ comm->comm_str = old;
+ return;
+ }
+
+ comm->start = timestamp;
+ comm_str__get(comm->comm_str);
+ comm_str__put(old);
+}
+
void comm__free(struct comm *comm)
{
comm_str__put(comm->comm_str);
diff --git a/tools/perf/util/comm.h b/tools/perf/util/comm.h
index f62d215bede2..7a86e5656710 100644
--- a/tools/perf/util/comm.h
+++ b/tools/perf/util/comm.h
@@ -16,5 +16,6 @@ struct comm {
void comm__free(struct comm *comm);
struct comm *comm__new(const char *str, u64 timestamp);
const char *comm__str(const struct comm *comm);
+void comm__override(struct comm *comm, const char *str, u64 timestamp);
#endif /* __PERF_COMM_H */
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 7e80253074b0..30793f98c8bb 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -416,6 +416,7 @@ struct hist_entry *__hists__add_mem_entry(struct hists
*hists,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = thread__comm(al->thread),
.ms = {
.map= al->map,
.sym= al->sym,
@@ -446,6 +447,7 @@ struct hist_entry *__hists__add_branch_entry(struct hists
*hists,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = thread__comm(al->thread),
.ms = {
.map= bi->to.map,
.sym= bi->to.sym,
@@ -475,6 +477,7 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
{
struct hist_entry entry = {
.thread = al->thread,
+ .comm = thread__comm(al->thread),
.ms = {
.map= al->map,
.sym= al->sym,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index bf91d0e5c16e..3c1b75c8b9a6 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1,5 +1,6 @@
#include "sort.h"
#include "hist.h"
+#include "comm.h"
#include "symbol.h"
regex_tparent_regex;
@@ -81,25 +82,20 @@ static int64_t
sort__comm_cmp(struct hist_entry *left, struct hist_entry *right)
{
/* Compare the addr that should be unique among comm */
- return thread__comm_str(right->thread) - thread__comm_str(left->thread);
+ return comm__str(right->comm) - comm__str(left->comm);
}
static int64_t
sort__comm_collapse(struct hist_entry *left, struct hist_entry *right)
{
- const char *comm_l = thread__comm_str(left->thread);
- const char *comm_r = thread__comm_str(right->thread);
-
- if (!comm_l || !comm_r)
- return cmp_null(comm_l, comm_r);
-
- return strcmp(comm_l, comm_r);
+ /* Compare the addr that should be unique among comm */
+ return comm__str(right->comm) - comm__str(left->comm);
}
static int hist_entry__comm_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
- return repsep_snprintf(bf, size, "%*s", width,
thread__comm_str(he->thread));
+ return repsep_snprintf(bf, size, "%*s", width, comm__str(he->comm));
}
struct sort_entry sort_comm = {
diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
index bf4333694d3a..f4e16f359d64 100644
--- a/tools/perf/util/sort.h
+++ b/tools/perf/util/sort.h
@@ -84,6 +84,7 @@ struct hist_entry {
struct he_stat stat;
struct map_symbol ms;
struct thread *thread;
+ struct comm *comm;
u64 ip;
u64 transaction;
s32 cpu;
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 15c53c2e109e..cd8e2f592719
[PATCH 29/29] tools lib traceevent: Add pevent_print_func_field() helper function
From: Steven Rostedt
Add the pevent_print_func_field() that will look up a field that is
expected to be a function pointer, and it will print the function name
and offset of the address given by the field.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215501.869542...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 42 ++
tools/lib/traceevent/event-parse.h | 4
2 files changed, 46 insertions(+)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index fc6f35f591f6..8f450adaa9c2 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -5367,6 +5367,48 @@ int pevent_print_num_field(struct trace_seq *s, const
char *fmt,
return -1;
}
+/**
+ * pevent_print_func_field - print a field and a format for function pointers
+ * @s: The seq to print to
+ * @fmt: The printf format to print the field with.
+ * @event: the event that the field is for
+ * @name: The name of the field
+ * @record: The record with the field name.
+ * @err: print default error if failed.
+ *
+ * Returns: 0 on success, -1 field not found, or 1 if buffer is full.
+ */
+int pevent_print_func_field(struct trace_seq *s, const char *fmt,
+ struct event_format *event, const char *name,
+ struct pevent_record *record, int err)
+{
+ struct format_field *field = pevent_find_field(event, name);
+ struct pevent *pevent = event->pevent;
+ unsigned long long val;
+ struct func_map *func;
+ char tmp[128];
+
+ if (!field)
+ goto failed;
+
+ if (pevent_read_number_field(field, record->data, ))
+ goto failed;
+
+ func = find_func(pevent, val);
+
+ if (func)
+ snprintf(tmp, 128, "%s/0x%llx", func->func, func->addr - val);
+ else
+ sprintf(tmp, "0x%08llx", val);
+
+ return trace_seq_printf(s, fmt, tmp);
+
+ failed:
+ if (err)
+ trace_seq_printf(s, "CAN'T FIND FIELD \"%s\"", name);
+ return -1;
+}
+
static void free_func_handle(struct pevent_function_handler *func)
{
struct pevent_func_params *params;
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index dc8539ee9485..8d73d2594f65 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -569,6 +569,10 @@ int pevent_print_num_field(struct trace_seq *s, const char
*fmt,
struct event_format *event, const char *name,
struct pevent_record *record, int err);
+int pevent_print_func_field(struct trace_seq *s, const char *fmt,
+ struct event_format *event, const char *name,
+ struct pevent_record *record, int err);
+
int pevent_register_event_handler(struct pevent *pevent, int id,
const char *sys_name, const char *event_name,
pevent_event_handler_func func, void
*context);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/29] perf evsel: Always use perf_evsel__set_sample_bit()
From: Adrian Hunter
Always use perf_evsel__set_sample_bit() rather than just setting the
bit.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-8-git-send-email-adrian.hun...@intel.com
[ Cope with 3090ffb "perf: Disable PERF_RECORD_MMAP2 support" ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index f0e65dec66a5..47bbf03aa7ef 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -663,7 +663,7 @@ void perf_evsel__config(struct perf_evsel *evsel,
}
if (opts->sample_address)
- attr->sample_type |= PERF_SAMPLE_DATA_SRC;
+ perf_evsel__set_sample_bit(evsel, DATA_SRC);
if (opts->no_delay) {
attr->watermark = 0;
@@ -675,13 +675,13 @@ void perf_evsel__config(struct perf_evsel *evsel,
}
if (opts->sample_weight)
- attr->sample_type |= PERF_SAMPLE_WEIGHT;
+ perf_evsel__set_sample_bit(evsel, WEIGHT);
attr->mmap = track;
attr->comm = track;
if (opts->sample_transaction)
- attr->sample_type |= PERF_SAMPLE_TRANSACTION;
+ perf_evsel__set_sample_bit(evsel, TRANSACTION);
/*
* XXX see the function comment above
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 20/29] perf top: Use parse_options_usage() for -s option failure
From: Namhyung Kim
The -s (--sort) option was processed after normal option parsing so that
it cannot call the parse_options_usage() automatically. Currently it
calls usage_with_options() which shows entire help messages for event
option. Fix it by showing just -s options.
$ perf top -s help
Error: Unknown --sort key: `help'
usage: perf top []
-s, --sort
sort by key(s): pid, comm, dso, symbol, ...
Signed-off-by: Namhyung Kim
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-5-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-top.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 21db76d71ddf..ca5ca37980fb 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -1040,7 +1040,7 @@ parse_percent_limit(const struct option *opt, const char
*arg,
int cmd_top(int argc, const char **argv, const char *prefix __maybe_unused)
{
- int status;
+ int status = -1;
char errbuf[BUFSIZ];
struct perf_top top = {
.count_filter= 5,
@@ -1159,8 +1159,10 @@ int cmd_top(int argc, const char **argv, const char
*prefix __maybe_unused)
if (sort_order == default_sort_order)
sort_order = "dso,symbol";
- if (setup_sorting() < 0)
- usage_with_options(top_usage, options);
+ if (setup_sorting() < 0) {
+ parse_options_usage(top_usage, options, "s", 1);
+ goto out_delete_evlist;
+ }
/* display thread wants entries to be collapsed in a different tree */
sort__need_collapse = 1;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 21/29] perf stat: Enhance option parse error message
From: Namhyung Kim
Print related option help messages only when it failed to process
options. While at it, modify parse_options_usage() to skip usage part
so that it can be used for showing multiple option help messages
naturally like below:
$ perf stat -Bx, ls
-B option not supported with -x
usage: perf stat [] []
-B, --big-num print large numbers with thousands' separators
-x, --field-separator
print counts with custom separator
Signed-off-by: Namhyung Kim
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-6-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-stat.c | 42 ++---
tools/perf/util/parse-options.c | 3 ++-
2 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 1a9c95d270aa..0fc1c941a73c 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1596,7 +1596,7 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
"perf stat [] []",
NULL
};
- int status = -ENOMEM, run_idx;
+ int status = -EINVAL, run_idx;
const char *mode;
setlocale(LC_ALL, "");
@@ -1614,12 +1614,15 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
if (output_name && output_fd) {
fprintf(stderr, "cannot use both --output and --log-fd\n");
- usage_with_options(stat_usage, options);
+ parse_options_usage(stat_usage, options, "o", 1);
+ parse_options_usage(NULL, options, "log-fd", 0);
+ goto out;
}
if (output_fd < 0) {
fprintf(stderr, "argument to --log-fd must be a > 0\n");
- usage_with_options(stat_usage, options);
+ parse_options_usage(stat_usage, options, "log-fd", 0);
+ goto out;
}
if (!output) {
@@ -1656,7 +1659,9 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
/* User explicitly passed -B? */
if (big_num_opt == 1) {
fprintf(stderr, "-B option not supported with -x\n");
- usage_with_options(stat_usage, options);
+ parse_options_usage(stat_usage, options, "B", 1);
+ parse_options_usage(NULL, options, "x", 1);
+ goto out;
} else /* Nope, so disable big number formatting */
big_num = false;
} else if (big_num_opt == 0) /* User passed --no-big-num */
@@ -1666,7 +1671,9 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
usage_with_options(stat_usage, options);
if (run_count < 0) {
- usage_with_options(stat_usage, options);
+ pr_err("Run count must be a positive number\n");
+ parse_options_usage(stat_usage, options, "r", 1);
+ goto out;
} else if (run_count == 0) {
forever = true;
run_count = 1;
@@ -1678,8 +1685,10 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
fprintf(stderr, "both cgroup and no-aggregation "
"modes only available in system-wide mode\n");
- usage_with_options(stat_usage, options);
- return -1;
+ parse_options_usage(stat_usage, options, "G", 1);
+ parse_options_usage(NULL, options, "A", 1);
+ parse_options_usage(NULL, options, "a", 1);
+ goto out;
}
if (add_default_attributes())
@@ -1688,25 +1697,28 @@ int cmd_stat(int argc, const char **argv, const char
*prefix __maybe_unused)
perf_target__validate();
if (perf_evlist__create_maps(evsel_list, ) < 0) {
- if (perf_target__has_task())
+ if (perf_target__has_task()) {
pr_err("Problems finding threads of monitor\n");
- if (perf_target__has_cpu())
+ parse_options_usage(stat_usage, options, "p", 1);
+ parse_options_usage(NULL, options, "t", 1);
+ } else if (perf_target__has_cpu()) {
perror("failed to parse CPUs map");
-
- usage_with_options(stat_usage, options);
- return -1;
+ parse_options_usage(stat_usage, options, "C", 1);
+ parse_options_usage(NULL, options, "a", 1);
+ }
+ goto out;
}
if (interval && interval < 100) {
Re: [PATCH 09/11] ARM: msm: Add SMP support for KPSSv2
On 11/01, Janakiram Sistla wrote:
> On 1 November 2013 15:08, Stephen Boyd wrote:
> > + err = -ENOMEM;
> > + goto err_map;
> > + }
> > +
> > + l2_saw_base = of_iomap(l2_node, 0);
> > + if (!l2_saw_base) {
> > + err = -ENOMEM;
> > + goto err_l2_map;
> > + }
> > +
> > + /* Turn on the BHS, turn off LDO Bypass and power down LDO */
> > + reg_val = 0x403f0001;
> >
> I think patch looks more nice if this hard coding is defined in terms of
> macros
>
> > + writel_relaxed(reg_val, reg + APC_PWR_GATE_CTL);
> > +
> > + /* complete the above write before the delay */
> > + mb();
> > + /* wait for the bhs to settle */
> > + udelay(1);
> > +
> > + /* Turn on BHS segments */
> > + reg_val |= 0x3f << 1;
> >
> same as above
>
Ok. I'll see what I can do.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/29] perf tools: Show single option when failed to parse
From: Namhyung Kim
Current option parser outputs whole option help string when it failed to
parse an option. However this is not good for user if the command has
many option, she might feel hard which one is related easily.
Fix it by just showing the help message of the given option only.
Signed-off-by: Namhyung Kim
Requested-by: Ingo Molnar
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-options.c | 217
tools/perf/util/parse-options.h | 4 +-
2 files changed, 132 insertions(+), 89 deletions(-)
diff --git a/tools/perf/util/parse-options.c b/tools/perf/util/parse-options.c
index 2bc9e70df7e2..1caf7b9a01ee 100644
--- a/tools/perf/util/parse-options.c
+++ b/tools/perf/util/parse-options.c
@@ -339,10 +339,10 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
if (arg[1] != '-') {
ctx->opt = arg + 1;
if (internal_help && *ctx->opt == 'h')
- return parse_options_usage(usagestr, options);
+ return usage_with_options_internal(usagestr,
options, 0);
switch (parse_short_opt(ctx, options)) {
case -1:
- return parse_options_usage(usagestr, options);
+ return parse_options_usage(usagestr, options,
arg + 1, 1);
case -2:
goto unknown;
default:
@@ -352,10 +352,11 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
check_typos(arg + 1, options);
while (ctx->opt) {
if (internal_help && *ctx->opt == 'h')
- return parse_options_usage(usagestr,
options);
+ return
usage_with_options_internal(usagestr, options, 0);
+ arg = ctx->opt;
switch (parse_short_opt(ctx, options)) {
case -1:
- return parse_options_usage(usagestr,
options);
+ return parse_options_usage(usagestr,
options, arg, 1);
case -2:
/* fake a short option thing to hide
the fact that we may have
* started to parse aggregated stuff
@@ -383,12 +384,12 @@ int parse_options_step(struct parse_opt_ctx_t *ctx,
if (internal_help && !strcmp(arg + 2, "help-all"))
return usage_with_options_internal(usagestr, options,
1);
if (internal_help && !strcmp(arg + 2, "help"))
- return parse_options_usage(usagestr, options);
+ return usage_with_options_internal(usagestr, options,
0);
if (!strcmp(arg + 2, "list-opts"))
return PARSE_OPT_LIST;
switch (parse_long_opt(ctx, arg + 2, options)) {
case -1:
- return parse_options_usage(usagestr, options);
+ return parse_options_usage(usagestr, options, arg + 2,
0);
case -2:
goto unknown;
default:
@@ -445,6 +446,89 @@ int parse_options(int argc, const char **argv, const
struct option *options,
#define USAGE_OPTS_WIDTH 24
#define USAGE_GAP 2
+static void print_option_help(const struct option *opts, int full)
+{
+ size_t pos;
+ int pad;
+
+ if (opts->type == OPTION_GROUP) {
+ fputc('\n', stderr);
+ if (*opts->help)
+ fprintf(stderr, "%s\n", opts->help);
+ return;
+ }
+ if (!full && (opts->flags & PARSE_OPT_HIDDEN))
+ return;
+
+ pos = fprintf(stderr, "");
+ if (opts->short_name)
+ pos += fprintf(stderr, "-%c", opts->short_name);
+ else
+ pos += fprintf(stderr, "");
+
+ if (opts->long_name && opts->short_name)
+ pos += fprintf(stderr, ", ");
+ if (opts->long_name)
+ pos += fprintf(stderr, "--%s", opts->long_name);
+
+ switch (opts->type) {
+ case OPTION_ARGUMENT:
+ break;
+ case OPTION_LONG:
+ case OPTION_U64:
+ case OPTION_INTEGER:
+ case OPTION_UINTEGER:
+ if (opts->flags & PARSE_OPT_OPTARG)
+ if (opts->long_name)
+ pos += fprintf(stderr, "[=]");
+
[PATCH 23/29] tools lib traceevent: Update printk formats when entered
From: "Steven Rostedt (Red Hat)"
Instead of cropping off the '"' and '\n"' from a printk format every
time it is referenced, do it when it's added. This makes it easier to
reference a printk_map and should speed things up a little.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215500.495619...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 29 ++---
tools/lib/traceevent/event-parse.h | 2 +-
2 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index deedff9d06af..856b79105abc 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -604,10 +604,11 @@ find_printk(struct pevent *pevent, unsigned long long
addr)
* This registers a string by the address it was stored in the kernel.
* The @fmt passed in is duplicated.
*/
-int pevent_register_print_string(struct pevent *pevent, char *fmt,
+int pevent_register_print_string(struct pevent *pevent, const char *fmt,
unsigned long long addr)
{
struct printk_list *item = malloc(sizeof(*item));
+ char *p;
if (!item)
return -1;
@@ -615,10 +616,21 @@ int pevent_register_print_string(struct pevent *pevent,
char *fmt,
item->next = pevent->printklist;
item->addr = addr;
+ /* Strip off quotes and '\n' from the end */
+ if (fmt[0] == '"')
+ fmt++;
item->printk = strdup(fmt);
if (!item->printk)
goto out_free;
+ p = item->printk + strlen(item->printk) - 1;
+ if (*p == '"')
+ *p = 0;
+
+ p -= 2;
+ if (strcmp(p, "\\n") == 0)
+ *p = 0;
+
pevent->printklist = item;
pevent->printk_count++;
@@ -3887,7 +3899,6 @@ get_bprint_format(void *data, int size __maybe_unused,
struct format_field *field;
struct printk_map *printk;
char *format;
- char *p;
field = pevent->bprint_fmt_field;
@@ -3909,20 +3920,8 @@ get_bprint_format(void *data, int size __maybe_unused,
return format;
}
- p = printk->printk;
- /* Remove any quotes. */
- if (*p == '"')
- p++;
- if (asprintf(, "%s : %s", "%pf", p) < 0)
+ if (asprintf(, "%s : %s", "%pf", printk->printk) < 0)
return NULL;
- /* remove ending quotes and new line since we will add one too */
- p = format + strlen(format) - 1;
- if (*p == '"')
- *p = 0;
-
- p -= 2;
- if (strcmp(p, "\\n") == 0)
- *p = 0;
return format;
}
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index 7503edf5ac6a..9ab6367f2fe9 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -533,7 +533,7 @@ int pevent_register_comm(struct pevent *pevent, const char
*comm, int pid);
void pevent_register_trace_clock(struct pevent *pevent, char *trace_clock);
int pevent_register_function(struct pevent *pevent, char *name,
unsigned long long addr, char *mod);
-int pevent_register_print_string(struct pevent *pevent, char *fmt,
+int pevent_register_print_string(struct pevent *pevent, const char *fmt,
unsigned long long addr);
int pevent_pid_is_registered(struct pevent *pevent, int pid);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/29] perf report: Postpone setting up browser after parsing options
From: Namhyung Kim
If setup_browser() called earlier than option parsing, the actual error
message can be discarded during the terminal reset. So move it after
setup_sorting() checks whether the sort keys are valid.
Signed-off-by: Namhyung Kim
Acked-by: Ingo Molnar
Reviewed-by: Ingo Molnar
Enthusiastically-Supported-by: Ingo Molnar
Cc: David Ahern
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link:
http://lkml.kernel.org/r/1383291195-24386-3-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 98d3891392e2..4df3161c7df2 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -905,13 +905,6 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
input_name = "perf.data";
}
- if (strcmp(input_name, "-") != 0)
- setup_browser(true);
- else {
- use_browser = 0;
- perf_hpp__init();
- }
-
file.path = input_name;
file.force = report.force;
@@ -957,6 +950,18 @@ repeat:
if (setup_sorting() < 0)
usage_with_options(report_usage, options);
+ if (parent_pattern != default_parent_pattern) {
+ if (sort_dimension__add("parent") < 0)
+ goto error;
+ }
+
+ if (strcmp(input_name, "-") != 0)
+ setup_browser(true);
+ else {
+ use_browser = 0;
+ perf_hpp__init();
+ }
+
/*
* Only in the TUI browser we are doing integrated annotation,
* so don't allocate extra space that won't be used in the stdio
@@ -986,11 +991,6 @@ repeat:
if (symbol__init() < 0)
goto error;
- if (parent_pattern != default_parent_pattern) {
- if (sort_dimension__add("parent") < 0)
- goto error;
- }
-
if (argc) {
/*
* Special case: if there's an argument left then assume that
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/29] perf evsel: Add a debug print if perf_event_open fails
From: Adrian Hunter
There is a debug print (at verbose level 2) for each call to
perf_event_open. Add another debug print if the call fails, and print
the error number.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-2-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 3a334f001997..f0e65dec66a5 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1051,6 +1051,8 @@ retry_open:
group_fd,
flags);
if (FD(evsel, cpu, thread) < 0) {
err = -errno;
+ pr_debug2("perf_event_open failed, error %d\n",
+ err);
goto try_fallback;
}
set_rlimit = NO_CHANGE;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 28/29] tools lib traceevent: Add flags NOHANDLE and PRINTRAW to individual events
From: Steven Rostedt
Add the flags EVENT_FL_NOHANDLE and EVENT_FL_PRINTRAW to the event flags
to have the event either ignore the register handler or to ignore the
handler and also print the raw format respectively.
This allows a tool to force a raw format or non handle for an event.
Signed-off-by: Steven Rostedt
Cc: Andrew Morton
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Link: http://lkml.kernel.org/r/20131101215501.655258...@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 4 ++--
tools/lib/traceevent/event-parse.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 85cbbddb6880..fc6f35f591f6 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -4446,11 +4446,11 @@ void pevent_event_info(struct trace_seq *s, struct
event_format *event,
{
int print_pretty = 1;
- if (event->pevent->print_raw)
+ if (event->pevent->print_raw || (event->flags & EVENT_FL_PRINTRAW))
print_event_fields(s, record->data, record->size, event);
else {
- if (event->handler)
+ if (event->handler && !(event->flags & EVENT_FL_NOHANDLE))
print_pretty = event->handler(s, record, event,
event->context);
diff --git a/tools/lib/traceevent/event-parse.h
b/tools/lib/traceevent/event-parse.h
index 9ab6367f2fe9..dc8539ee9485 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -308,6 +308,8 @@ enum {
EVENT_FL_ISBPRINT = 0x04,
EVENT_FL_ISFUNCENT = 0x10,
EVENT_FL_ISFUNCRET = 0x20,
+ EVENT_FL_NOHANDLE = 0x40,
+ EVENT_FL_PRINTRAW = 0x80,
EVENT_FL_FAILED = 0x8000
};
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/29] perf evsel: Add missing overflow check for TRANSACTION
From: Adrian Hunter
Add missing overflow check for PERF_SAMPLE_TRANSACTION in
perf_evsel__parse_sample().
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-9-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 47bbf03aa7ef..b121717ce42a 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1481,6 +1481,7 @@ int perf_evsel__parse_sample(struct perf_evsel *evsel,
union perf_event *event,
data->transaction = 0;
if (type & PERF_SAMPLE_TRANSACTION) {
+ OVERFLOW_CHECK_u64(array);
data->transaction = *array;
array++;
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/29] perf tools: Fix 32-bit cross build
From: Adrian Hunter Setting EXTRA_CFLAGS=-m32 did not work because it was not passed around. Signed-off-by: Adrian Hunter Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1383313899-15987-4-git-send-email-adrian.hun...@intel.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 2 +- tools/perf/config/Makefile| 4 ++-- tools/perf/config/feature-checks/Makefile | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index cb52bdb755c7..5b8639025aae 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -711,7 +711,7 @@ $(LIB_FILE): $(LIB_OBJS) TE_SOURCES = $(wildcard $(TRACE_EVENT_DIR)*.[ch]) $(LIBTRACEEVENT): $(TE_SOURCES) - $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) libtraceevent.a + $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) CFLAGS="-g -Wall $(EXTRA_CFLAGS)" libtraceevent.a $(LIBTRACEEVENT)-clean: $(call QUIET_CLEAN, libtraceevent) diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index 543aa953bab1..2f1d7d78f744 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -96,7 +96,7 @@ endif feature_check = $(eval $(feature_check_code)) define feature_check_code - feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) + feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0) endef feature_set = $(eval $(feature_set_code)) @@ -173,7 +173,7 @@ ifeq ($(feature-all), 1) # $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat))) else - $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1) + $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CFLAGS="$(EXTRA_CFLAGS)" LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1) $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat))) endif diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index 452b67cc4d7b..353c00cde4d6 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -31,7 +31,7 @@ CC := $(CC) -MD all: $(FILES) -BUILD = $(CC) $(LDFLAGS) -o $(OUTPUT)$@ $@.c +BUILD = $(CC) $(CFLAGS) $(LDFLAGS) -o $(OUTPUT)$@ $@.c ### -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] perf tools: Check maximum frequency rate for record/top
Em Mon, Nov 04, 2013 at 04:32:16PM +0100, Jiri Olsa escreveu: > On Mon, Nov 04, 2013 at 08:17:24AM -0700, David Ahern wrote: > > On 11/4/13, 4:06 AM, Jiri Olsa wrote: > > >Adding the check for maximum allowed frequency rate > > >defined in following file: > > > /proc/sys/kernel/perf_event_max_sample_rate > > > > > >When we cross the maximum value we fail and display > > >detailed error message with advise. > > > > perf commands should automatically adjust the default frequency too. > > If the user did not specify a frequency then this message is going > > to be confusing. > > ok, I'll add that check and probably some warning > if we are force to go below the default rate. I think we should just make it clear the frequency used and pick the best according to the hardware. And we are not doing gthat at all, at least in the TUI, need to change that. Only in the stdio, with that long list of commented lines, that should as well be hidden, too verbose. And here we also see the frequency used: [root@zoo linux]# perf evlist -v cycles: sample_freq=4000, size: 96, sample_type: IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 [root@zoo linux]# > > > Though the algorithm that keeps lowering the rate should be tweaked as well. > > yea.. I was thinking putting the max rate back up after > some sane period > > or/plus having 'echo 0 > /proc/sys/kernel/perf_event_max_sample_rate' to > disable it completely > > jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 27/29] tools lib traceevent: Check for spaces in character array
From: "Steven Rostedt (Red Hat)" Currently when using the raw format for fields, when looking at a character array, to determine if it is a string or not, we make sure all characters are "isprint()". If not, then we consider it a numeric array, and print the hex numbers of the characters instead. But it seems that '\n' fails the isprint() check! Add isspace() to the check as well, such that if all characters pass isprint() or isspace() it will assume the character array is a string. Reported-by: Xenia Ragiadakou Signed-off-by: Steven Rostedt Cc: Andrew Morton Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Xenia Ragiadakou Link: http://lkml.kernel.org/r/20131101215501.465091...@goodmis.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/lib/traceevent/event-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c index e1c743c52834..85cbbddb6880 100644 --- a/tools/lib/traceevent/event-parse.c +++ b/tools/lib/traceevent/event-parse.c @@ -3981,7 +3981,7 @@ static int is_printable_array(char *p, unsigned int len) unsigned int i; for (i = 0; i < len && p[i]; i++) - if (!isprint(p[i])) + if (!isprint(p[i]) && !isspace(p[i])) return 0; return 1; } -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] (xen) stable/for-jens-3.12 for Jens Axboe
On Mon, Nov 04, 2013 at 10:40:02AM -0700, Jens Axboe wrote: > On 11/04/2013 10:37 AM, Konrad Rzeszutek Wilk wrote: > > On Fri, Sep 06, 2013 at 02:26:34PM -0600, Jens Axboe wrote: > >> On 09/06/2013 02:25 PM, Konrad Rzeszutek Wilk wrote: > >>> Hey Jens, > >>> > >>> I sent you a git pull a couple of weeks ago but I am not sure if > >>> you pulled it. It does not look like it, so here it is again along > >>> with an extra bug-fix. > >>> > >>> Please git pull: > >>> > >>> git pull git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > >>> stable/for-jens-3.12 > >>> > >>> which will give you bug-fixes to Xen blkfront and backend driver: > >> > >> Thanks, I'll get the 3.12 branch set up and pulled in. I'm behind on a > >> lot of other drivers, too. > > > > Hm, looks like you never pulled that for v3.12. > > It is in: > > axboe@axboe ~/git/linux-block $ git pull > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > stable/for-jens-3.12 > >From git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip > * branchstable/for-jens-3.12 -> FETCH_HEAD > Merge made by the 'recursive' strategy. > axboe@axboe ~/git/linux-block $ My apologies! I should have of course checked your tree more carefully. > > > There is one more patch that Roger has provided. Do you want to pull > > this branch for v3.13 nowish or wait until I put in Roger's patch? > > You'll need to queue that up or send as a patch separately.-- OK. > Jens Axboe > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/29] perf test: Update "sample parsing" test for PERF_SAMPLE_TRANSACTION
From: Adrian Hunter
In fact the "sample parsing" test does not automatically check new
sample type bits - they must be added to the comparison logic.
Doing that shows that the test fails because the functions
perf_event__synthesize_sample() and perf_event__sample_event_size() have
not been updated with PERF_SAMPLE_TRANSACTION either.
Signed-off-by: Adrian Hunter
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-10-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/sample-parsing.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/perf/tests/sample-parsing.c
b/tools/perf/tests/sample-parsing.c
index 61c9da2eb3a9..1b677202638d 100644
--- a/tools/perf/tests/sample-parsing.c
+++ b/tools/perf/tests/sample-parsing.c
@@ -121,6 +121,9 @@ static bool samples_same(const struct perf_sample *s1,
if (type & PERF_SAMPLE_DATA_SRC)
COMP(data_src);
+ if (type & PERF_SAMPLE_TRANSACTION)
+ COMP(transaction);
+
return true;
}
@@ -165,6 +168,7 @@ static int do_test(u64 sample_type, u64 sample_regs_user,
u64 read_format)
.cpu= 110,
.raw_size = sizeof(raw_data),
.data_src = 111,
+ .transaction= 112,
.raw_data = (void *)raw_data,
.callchain = ,
.branch_stack = _stack.branch_stack,
@@ -273,7 +277,8 @@ int test__sample_parsing(void)
/*
* Fail the test if it has not been updated when new sample format bits
-* were added.
+* were added. Please actually update the test rather than just change
+* the condition below.
*/
if (PERF_SAMPLE_MAX > PERF_SAMPLE_TRANSACTION << 1) {
pr_debug("sample format has changed, some new PERF_SAMPLE_ bit
was introduced - test needs updating\n");
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/29] perf evsel: Synthesize PERF_SAMPLE_TRANSACTION
From: Adrian Hunter
Add missing PERF_SAMPLE_TRANSACTION to perf_event__synthesize_sample()
and perf_event__sample_event_size().
This makes the "sample parsing" test pass.
Signed-off-by: Adrian Hunter
Cc: Andi Kleen
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-11-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.c | 8
1 file changed, 8 insertions(+)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index b121717ce42a..5280820ed389 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1578,6 +1578,9 @@ size_t perf_event__sample_event_size(const struct
perf_sample *sample, u64 type,
if (type & PERF_SAMPLE_DATA_SRC)
result += sizeof(u64);
+ if (type & PERF_SAMPLE_TRANSACTION)
+ result += sizeof(u64);
+
return result;
}
@@ -1751,6 +1754,11 @@ int perf_event__synthesize_sample(union perf_event
*event, u64 type,
array++;
}
+ if (type & PERF_SAMPLE_TRANSACTION) {
+ *array = sample->transaction;
+ array++;
+ }
+
return 0;
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/29] perf tools: Use an accessor to read thread comm
From: Frederic Weisbecker
As the thread comm is going to be implemented by way of a more
complicated data structure than just a pointer to a string from the
thread struct, convert the readers of comm to use an accessor instead of
accessing it directly.
The accessor will be later overriden to support an enhanced comm
implementation.
Signed-off-by: Frederic Weisbecker
Tested-by: Jiri Olsa
Cc: Jiri Olsa
Cc: David Ahern
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Stephane Eranian
Link: http://lkml.kernel.org/n/tip-wr683zwy94hmj4ibogmnv...@git.kernel.org
[ Rename thread__comm_curr() to thread__comm_str() ]
Signed-off-by: Namhyung Kim
[ Fixed up some minor const pointer issues ]
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-kmem.c | 2 +-
tools/perf/builtin-lock.c | 2 +-
tools/perf/builtin-sched.c | 16
tools/perf/builtin-script.c| 6 +++---
tools/perf/tests/hists_link.c | 2 +-
tools/perf/ui/browsers/hists.c | 10 +-
tools/perf/util/event.c| 4 ++--
tools/perf/util/scripting-engines/trace-event-perl.c | 2 +-
tools/perf/util/scripting-engines/trace-event-python.c | 4 ++--
tools/perf/util/sort.c | 11 ++-
tools/perf/util/thread.c | 7 ++-
tools/perf/util/thread.h | 1 +
12 files changed, 37 insertions(+), 30 deletions(-)
diff --git a/tools/perf/builtin-kmem.c b/tools/perf/builtin-kmem.c
index 1126382659a9..a28970f7ddfb 100644
--- a/tools/perf/builtin-kmem.c
+++ b/tools/perf/builtin-kmem.c
@@ -315,7 +315,7 @@ static int process_sample_event(struct perf_tool *tool
__maybe_unused,
return -1;
}
- dump_printf(" ... thread: %s:%d\n", thread->comm, thread->tid);
+ dump_printf(" ... thread: %s:%d\n", thread__comm_str(thread),
thread->tid);
if (evsel->handler.func != NULL) {
tracepoint_handler f = evsel->handler.func;
diff --git a/tools/perf/builtin-lock.c b/tools/perf/builtin-lock.c
index 33c7253295b9..35f9aaa565cc 100644
--- a/tools/perf/builtin-lock.c
+++ b/tools/perf/builtin-lock.c
@@ -767,7 +767,7 @@ static void dump_threads(void)
while (node) {
st = container_of(node, struct thread_stat, rb);
t = perf_session__findnew(session, st->tid);
- pr_info("%10d: %s\n", st->tid, t->comm);
+ pr_info("%10d: %s\n", st->tid, thread__comm_str(t));
node = rb_next(node);
};
}
diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index ddb5dc15be17..a81ab1828aa5 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -737,12 +737,12 @@ static int replay_fork_event(struct perf_sched *sched,
if (verbose) {
printf("fork event\n");
- printf("... parent: %s/%d\n", parent->comm, parent->tid);
- printf("... child: %s/%d\n", child->comm, child->tid);
+ printf("... parent: %s/%d\n", thread__comm_str(parent),
parent->tid);
+ printf("... child: %s/%d\n", thread__comm_str(child),
child->tid);
}
- register_pid(sched, parent->tid, parent->comm);
- register_pid(sched, child->tid, child->comm);
+ register_pid(sched, parent->tid, thread__comm_str(parent));
+ register_pid(sched, child->tid, thread__comm_str(child));
return 0;
}
@@ -1077,7 +1077,7 @@ static int latency_migrate_task_event(struct perf_sched
*sched,
if (!atoms) {
if (thread_atoms_insert(sched, migrant))
return -1;
- register_pid(sched, migrant->tid, migrant->comm);
+ register_pid(sched, migrant->tid, thread__comm_str(migrant));
atoms = thread_atoms_search(>atom_root, migrant,
>cmp_pid);
if (!atoms) {
pr_err("migration-event: Internal tree error");
@@ -,13 +,13 @@ static void output_lat_thread(struct perf_sched *sched,
struct work_atoms *work_
/*
* Ignore idle threads:
*/
- if (!strcmp(work_list->thread->comm, "swapper"))
+ if (!strcmp(thread__comm_str(work_list->thread), "swapper"))
return;
sched->all_runtime += work_list->total_runtime;
sched->all_count += work_list->nb_atoms;
- ret = printf(" %s:%d ", work_list->thread->comm,
work_list->thread->tid);
+ ret = printf(" %s:%d ", thread__comm_str(work_list->thread),
work_list->thread->tid);
for (i = 0; i < 24 - ret; i++)
printf(" ");
@@ -1334,7 +1334,7 @@ static int map_switch_event(struct perf_sched *sched,
struct perf_evsel *evsel,
printf(" %12.6f secs ",
[PATCH 12/29] perf evlist: Add a debug print if event buffer mmap fails
From: Adrian Hunter
Add a debug print if mmap of the perf event ring buffer fails.
Signed-off-by: Adrian Hunter
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Mike Galbraith
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1383313899-15987-6-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 0582f67fbefc..1c173ccb0ef2 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -607,6 +607,8 @@ static int __perf_evlist__mmap(struct perf_evlist *evlist,
evlist->mmap[idx].base = mmap(NULL, evlist->mmap_len, prot,
MAP_SHARED, fd, 0);
if (evlist->mmap[idx].base == MAP_FAILED) {
+ pr_debug2("failed to mmap perf event ring buffer, error %d\n",
+ errno);
evlist->mmap[idx].base = NULL;
return -1;
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
