[PATCH v2] perf stat: Don't print bogus data for stalled-cycles

[Ramkumar Ramachandra]

When the stalled-cycles-frontend event is requested without the cycles
event:

  $ perf stat -e stalled-cycles-frontend -- git s
  ## acme...ram/acme

   Performance counter stats for 'git s':

 326,947,423  stalled-cycles-frontend   #0.00% frontend cycles 
idle

 0.363599976 seconds time elapsed

The 0.00% frontend cycles idle comment in the output is totally bogus
and misleading. Omit printing it here, as well as in the
stalled-cycles-backend case.

Cc: Jiri Olsa jo...@redhat.com
Cc: David Ahern dsah...@gmail.com
Cc: Arnaldo Carvalho de Melo a...@redhat.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 tools/perf/builtin-stat.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 8b0e1c9..0bd98fa 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -797,14 +797,13 @@ static void print_stalled_cycles_frontend(int cpu,
 
total = avg_stats(runtime_cycles_stats[cpu]);
 
-   if (total)
+   if (total) {
ratio = avg / total * 100.0;
-
-   color = get_ratio_color(GRC_STALLED_CYCLES_FE, ratio);
-
-   fprintf(output,  #  );
-   color_fprintf(output, color, %6.2f%%, ratio);
-   fprintf(output,  frontend cycles idle   );
+   color = get_ratio_color(GRC_STALLED_CYCLES_FE, ratio);
+   fprintf(output,  #  );
+   color_fprintf(output, color, %6.2f%%, ratio);
+   fprintf(output,  frontend cycles idle   );
+   }
 }
 
 static void print_stalled_cycles_backend(int cpu,
@@ -816,14 +815,13 @@ static void print_stalled_cycles_backend(int cpu,
 
total = avg_stats(runtime_cycles_stats[cpu]);
 
-   if (total)
+   if (total) {
ratio = avg / total * 100.0;
-
-   color = get_ratio_color(GRC_STALLED_CYCLES_BE, ratio);
-
-   fprintf(output,  #  );
-   color_fprintf(output, color, %6.2f%%, ratio);
-   fprintf(output,  backend  cycles idle   );
+   color = get_ratio_color(GRC_STALLED_CYCLES_BE, ratio);
+   fprintf(output,  #  );
+   color_fprintf(output, color, %6.2f%%, ratio);
+   fprintf(output,  backend  cycles idle   );
+   }
 }
 
 static void print_branch_misses(int cpu,
-- 
1.9.2.667.ge5b74e1

--
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/3] perf bench: Set more defaults in the 'numa' suite

[Ramkumar Ramachandra]

Jiri Olsa wrote:
  ###
  # 1 task will execute (on 1 nodes, 4 CPUs):
  # -1x 1MB global  shared mem operations
  # -1x 0MB process shared mem operations
  # -1x 0MB thread  local  mem operations
  ###
 ...


 '-1x' does not seem right/intentional for default case

As you can see from print_summary(), -1 is the value of nr_loops. In
init_params(), Ingo set nr_loops is set to -1 in his original patch --
I haven't touched that. So, unless I'm missing something, it's quite
an apt default case.

Ram
--
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 v2] perf list: Fix --raw-dump argument

[Ramkumar Ramachandra]

While adding usage information, 44d742e (perf list: Add usage,
2013-10-30) broke

  $ perf list --raw-dump

Fix this by making raw-dump a subcommand.

Cc: David Ahern dsah...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@redhat.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 tools/perf/builtin-list.c | 2 +-
 tools/perf/perf-completion.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..c74aef5 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -53,7 +53,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
print_hwcache_events(NULL, false);
else if (strcmp(argv[i], pmu) == 0)
print_pmu_events(NULL, false);
-   else if (strcmp(argv[i], --raw-dump) == 0)
+   else if (strcmp(argv[i], raw-dump) == 0)
print_events(NULL, true);
else {
char *sep = strchr(argv[i], ':'), *s;
diff --git a/tools/perf/perf-completion.sh b/tools/perf/perf-completion.sh
index ae3a576..8f518f0 100644
--- a/tools/perf/perf-completion.sh
+++ b/tools/perf/perf-completion.sh
@@ -119,7 +119,7 @@ __perf_main ()
fi
# List possible events for -e option
elif [[ $prev == -e  ${words[1]} == @(record|stat|top) ]]; then
-   evts=$($cmd list --raw-dump)
+   evts=$($cmd list raw-dump)
__perfcomp_colon $evts $cur
# List subcommands for 'perf kvm'
elif [[ $prev == kvm ]]; then
-- 
1.9.2.667.ge5b74e1

--
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] perf list: Fix --raw-dump argument

[Ramkumar Ramachandra]

Jiri Olsa wrote:
 but looks like the usage is for bash completion only, so we probably
 need only the first example functionality above.

 If this is the case I think it should not be an option but another
 command like 'raw-dump'.

I decided that there's no point making it an option, so I've sent you
a patch making it a subcommand instead.

Thanks.
--
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] perf list: Fix --raw-dump argument

[Ramkumar Ramachandra]

Jiri Olsa wrote:
 you need to update perf-completion.sh now
 also please add it to perf list man page as well

I updated perf-completion.sh, although I didn't mention it in the
commit message. I'll add it to the perf-list man page and send out
another version.

Ram
--
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 v3] perf list: Fix --raw-dump argument

[Ramkumar Ramachandra]

While adding usage information, 44d742e (perf list: Add usage,
2013-10-30) broke

  $ perf list --raw-dump

Fix this by making raw-dump a subcommand. Also update the completion
script and manpage.

Cc: David Ahern dsah...@gmail.com
Cc: Jiri Olsa jo...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@redhat.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 tools/perf/Documentation/perf-list.txt | 3 +++
 tools/perf/builtin-list.c  | 2 +-
 tools/perf/perf-completion.sh  | 2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index 6fce6a6..13fe4f4 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -108,6 +108,9 @@ To limit the list use:
 
 . 'pmu' to print the kernel supplied PMU events.
 
+. 'raw-dump' to print out the names of all events. For internal use by
+  the completion script.
+
 . If none of the above is matched, it will apply the supplied glob to all
   events, printing the ones that match.
 
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..c74aef5 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -53,7 +53,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
print_hwcache_events(NULL, false);
else if (strcmp(argv[i], pmu) == 0)
print_pmu_events(NULL, false);
-   else if (strcmp(argv[i], --raw-dump) == 0)
+   else if (strcmp(argv[i], raw-dump) == 0)
print_events(NULL, true);
else {
char *sep = strchr(argv[i], ':'), *s;
diff --git a/tools/perf/perf-completion.sh b/tools/perf/perf-completion.sh
index ae3a576..8f518f0 100644
--- a/tools/perf/perf-completion.sh
+++ b/tools/perf/perf-completion.sh
@@ -119,7 +119,7 @@ __perf_main ()
fi
# List possible events for -e option
elif [[ $prev == -e  ${words[1]} == @(record|stat|top) ]]; then
-   evts=$($cmd list --raw-dump)
+   evts=$($cmd list raw-dump)
__perfcomp_colon $evts $cur
# List subcommands for 'perf kvm'
elif [[ $prev == kvm ]]; then
-- 
1.9.2.667.ge5b74e1

--
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 v2] avr32: replace simple_strtoul() with kstrtoul()

[Ramkumar Ramachandra]

simple_strtoul() is marked for obsoletion; use the newer and more
pleasant kstrtoul() in its place.

Cc: Alexey Dobriyan adobri...@gmail.com
Cc: Haavard Skinnemoen hskinnem...@gmail.com
Cc: Hans-Christian Egtvedt egtv...@samfundet.no
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 arch/avr32/kernel/cpu.c | 48 ++--
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/arch/avr32/kernel/cpu.c b/arch/avr32/kernel/cpu.c
index 2233be7..20ce2c0 100644
--- a/arch/avr32/kernel/cpu.c
+++ b/arch/avr32/kernel/cpu.c
@@ -39,10 +39,12 @@ static ssize_t store_pc0event(struct device *dev,
  size_t count)
 {
unsigned long val;
-   char *endp;
+   int ret;
 
-   val = simple_strtoul(buf, endp, 0);
-   if (endp == buf || val  0x3f)
+   ret = kstrtoul(buf, 0, val);
+   if (ret)
+   return ret;
+   if (val  0x3f)
return -EINVAL;
val = (val  12) | (sysreg_read(PCCR)  0xfffc0fff);
sysreg_write(PCCR, val);
@@ -61,11 +63,11 @@ static ssize_t store_pc0count(struct device *dev,
const char *buf, size_t count)
 {
unsigned long val;
-   char *endp;
+   int ret;
 
-   val = simple_strtoul(buf, endp, 0);
-   if (endp == buf)
-   return -EINVAL;
+   ret = kstroul(buf, 0, val);
+   if (ret)
+   return ret;
sysreg_write(PCNT0, val);
 
return count;
@@ -84,10 +86,12 @@ static ssize_t store_pc1event(struct device *dev,
  size_t count)
 {
unsigned long val;
-   char *endp;
+   int ret;
 
-   val = simple_strtoul(buf, endp, 0);
-   if (endp == buf || val  0x3f)
+   ret = kstrtoul(buf, 0, val);
+   if (ret)
+   return ret;
+   if (val  0x3f)
return -EINVAL;
val = (val  18) | (sysreg_read(PCCR)  0xff03);
sysreg_write(PCCR, val);
@@ -106,11 +110,11 @@ static ssize_t store_pc1count(struct device *dev,
  size_t count)
 {
unsigned long val;
-   char *endp;
+   int ret;
 
-   val = simple_strtoul(buf, endp, 0);
-   if (endp == buf)
-   return -EINVAL;
+   ret = kstrtoul(buf, 0, val);
+   if (ret)
+   return ret;
sysreg_write(PCNT1, val);
 
return count;
@@ -129,11 +133,11 @@ static ssize_t store_pccycles(struct device *dev,
  size_t count)
 {
unsigned long val;
-   char *endp;
+   int ret;
 
-   val = simple_strtoul(buf, endp, 0);
-   if (endp == buf)
-   return -EINVAL;
+   ret = kstrtoul(buf, 0, val);
+   if (ret)
+   return ret;
sysreg_write(PCCNT, val);
 
return count;
@@ -152,11 +156,11 @@ static ssize_t store_pcenable(struct device *dev,
  size_t count)
 {
unsigned long pccr, val;
-   char *endp;
+   int ret;
 
-   val = simple_strtoul(buf, endp, 0);
-   if (endp == buf)
-   return -EINVAL;
+   ret = kstrtoul(buf, 0, val);
+   if (ret)
+   return ret;
if (val)
val = 1;
 
-- 
1.9.0.431.g014438b

--
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 0/4] Minor selftests cleanups

[Ramkumar Ramachandra]

Just ran a few of them.  Unsure about [4/4] because of aabccae6 and
a58130d.

Thanks.

Ramkumar Ramachandra (4):
  selftests: add .gitignore for vm
  selftests: fix clean target in kcmp Makefile
  selftests: add .gitignore for kcmp
  selftests: get {cpu,memory}-hotplug tests to run

 tools/testing/selftests/cpu-hotplug/on-off-test.sh| 0
 tools/testing/selftests/kcmp/.gitignore   | 2 ++
 tools/testing/selftests/kcmp/Makefile | 3 +--
 tools/testing/selftests/memory-hotplug/on-off-test.sh | 0
 tools/testing/selftests/vm/.gitignore | 4 
 5 files changed, 7 insertions(+), 2 deletions(-)
 mode change 100644 = 100755 tools/testing/selftests/cpu-hotplug/on-off-test.sh
 create mode 100644 tools/testing/selftests/kcmp/.gitignore
 mode change 100644 = 100755 
tools/testing/selftests/memory-hotplug/on-off-test.sh
 create mode 100644 tools/testing/selftests/vm/.gitignore

-- 
1.8.3.1.643.gebeea52.dirty

--
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 3/4] selftests: add .gitignore for kcmp

[Ramkumar Ramachandra]

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 tools/testing/selftests/kcmp/.gitignore | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 tools/testing/selftests/kcmp/.gitignore

diff --git a/tools/testing/selftests/kcmp/.gitignore 
b/tools/testing/selftests/kcmp/.gitignore
new file mode 100644
index 000..5a9b373
--- /dev/null
+++ b/tools/testing/selftests/kcmp/.gitignore
@@ -0,0 +1,2 @@
+kcmp_test
+kcmp-test-file
-- 
1.8.3.1.643.gebeea52.dirty

--
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/4] selftests: get {cpu,memory}-hotplug tests to run

[Ramkumar Ramachandra]

The cpu-hotplug and memory-hotplug tests don't run:

  $ sudo make -C tools/testing/selftests TARGETS=cpu-hotplug run_tests
  /bin/sh: ./on-off-test.sh: Permission denied

  $ sudo make -C tools/testing/selftests TARGETS=memory-hotplug run_tests
  /bin/sh: ./on-off-test.sh: Permission denied

Flip the executable bit fixing this.

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 tools/testing/selftests/cpu-hotplug/on-off-test.sh| 0
 tools/testing/selftests/memory-hotplug/on-off-test.sh | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 = 100755 tools/testing/selftests/cpu-hotplug/on-off-test.sh
 mode change 100644 = 100755 
tools/testing/selftests/memory-hotplug/on-off-test.sh

diff --git a/tools/testing/selftests/cpu-hotplug/on-off-test.sh 
b/tools/testing/selftests/cpu-hotplug/on-off-test.sh
old mode 100644
new mode 100755
diff --git a/tools/testing/selftests/memory-hotplug/on-off-test.sh 
b/tools/testing/selftests/memory-hotplug/on-off-test.sh
old mode 100644
new mode 100755
-- 
1.8.3.1.643.gebeea52.dirty

--
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/4] selftests: add .gitignore for vm

[Ramkumar Ramachandra]

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 tools/testing/selftests/vm/.gitignore | 4 
 1 file changed, 4 insertions(+)
 create mode 100644 tools/testing/selftests/vm/.gitignore

diff --git a/tools/testing/selftests/vm/.gitignore 
b/tools/testing/selftests/vm/.gitignore
new file mode 100644
index 000..ff1bb16
--- /dev/null
+++ b/tools/testing/selftests/vm/.gitignore
@@ -0,0 +1,4 @@
+hugepage-mmap
+hugepage-shm
+map_hugetlb
+thuge-gen
-- 
1.8.3.1.643.gebeea52.dirty

--
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/4] selftests: fix clean target in kcmp Makefile

[Ramkumar Ramachandra]

Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
 tools/testing/selftests/kcmp/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/testing/selftests/kcmp/Makefile 
b/tools/testing/selftests/kcmp/Makefile
index 56eb552..d7d6bbe 100644
--- a/tools/testing/selftests/kcmp/Makefile
+++ b/tools/testing/selftests/kcmp/Makefile
@@ -25,5 +25,4 @@ run_tests: all
@./kcmp_test || echo kcmp_test: [FAIL]
 
 clean:
-   rm -fr ./run_test
-   rm -fr ./test-file
+   $(RM) kcmp_test kcmp-test-file
-- 
1.8.3.1.643.gebeea52.dirty

--
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/1] perf:Adding --list-opts to usage string

[Ramkumar Ramachandra]

Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 08, 2015 at 10:59:50AM +0530, Sriram Raghunathan escreveu:
>> Minor change, adding --list-opts to usage string. So that it is
>> visible to the user on running perf --help. or just perf
>> from command line.
>
>
> Ramkumar, Yunlong, are you ok with this?

Not sure I understand the motivation, but I suppose it can't hurt to
show this detail?

Ram

>> Signed-off-by: Sriram Raghunathan 
>> ---
>>  tools/perf/perf.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/perf/perf.c b/tools/perf/perf.c
>> index 07dbff5..92b5007 100644
>> --- a/tools/perf/perf.c
>> +++ b/tools/perf/perf.c
>> @@ -19,7 +19,7 @@
>>  #include 
>>
>>  const char perf_usage_string[] =
>> - "perf [--version] [--help] [OPTIONS] COMMAND [ARGS]";
>> + "perf [--version] [--help] [--list-opts] [OPTIONS] COMMAND [ARGS]";
>>
>>  const char perf_more_info_string[] =
>>   "See 'perf help COMMAND' for more information on a specific command.";
>> --
>> 2.6.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: Beyond inotify recursive watches

[Ramkumar Ramachandra]

Jan Kara wrote:
>   Hum, I have somewhat hard time to understand what do you mean by
> 'magically optimized syscalls'. What should happen in VFS to speedup your
> load?

In retrospect, I think this is a terrible hack to begin with.  Tuning
the filesystem specifically for git repositories is inelegant on so
many levels, I can't recall why I ever thought it would be a good
idea.  Like all software, Git has scaling issues with ultra-large
repositories.  Too many stat() calls is just one of the problems:
there will be too many objects to do any operation at reasonable
speed, and the overall UX would just suck.  Instead of growing to a
huge monolithic beast that spawns off worker threads for everything
and ultimately dying off, I've decided that git should take a
different direction: it should work with well with many small
easily-composable repositories.  I've started work on this already,
and it looks very promising.

Let the filesystem people do what they do best: optimizing for all
applications uniformly.
--
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: [QUERY] lguest64

[Ramkumar Ramachandra]

H. Peter Anvin wrote:
> UML, lguest and Xen were done before the x86 architecture supported
> hardware virtualization.

[...]

> but on KVM-enabled hardware KVM seems
> like the better option (and is indeed what libguestfs uses.)

While we're still on the topic, I'd like a few clarifications. From
your reply, I got the impression that KVM the only mechanism for
non-pvops virtualization.  This seems quite contrary to what I read on
lwn about ARM virtualization [1]. In short, ARM provides a "hypervisor
mode", and the article says

  "the virtualization model provided by ARM fits the Xen
hypervisor-based virtualization better than KVM's kernel-based model"

The Xen people call this "ARM PVH" (as opposed to ARM PV, which does
not utilize hardware extensions) [2]. Although I wasn't able to find
much information about the hardware aspect, what ARM provides seems to
be quite different from VT-x and AMD-V. I'm also confused about what
virt/kvm/arm is.

Thanks.

[1]: http://lwn.net/Articles/513940/
[2]: http://www.xenproject.org/developers/teams/arm-hypervisor.html
--
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: Beyond inotify recursive watches

[Ramkumar Ramachandra]

[Dropping git people from the CC, as this is not relevant to git anymore]

Okay, let me attempt to understand this.

Jan Kara wrote:
> On Fri 05-04-13 17:12:29, Al Viro wrote:
>> On Fri, Apr 05, 2013 at 05:55:34PM +0200, Jan Kara wrote:
>>
>> > What your question reminds me is an idea of recursive modification time
>> > stamp on directories. That is a time stamp that gets updated whenever
>> > anything in the tree under the directory changes. Now this would be too
>> > expensive to maintain so there's also a trick implemented that you update
>> > the time stamp (and continue updating recursive time stamps upwards) only
>> > if a special flag is set on the directory. And you clear the flag at that
>> > moment. So until someone checks the time stamp and resets the flag no
>> > further updates of the recursive modification time happen.

If I understand correctly, I'll have to set a flag on the toplevel
directory of the repository, and this recursive timestamp update magic
will apply to my entire worktree.  How exactly?  Are you going to
store that path somewhere? Whenever there's any modification on the
filesystem, you can look at the path of the inode you're modifying,
and see if it's under this path.  If it is, we'll have to keep update
the container dentry's timestamp, and continue recursively until we
hit the toplevel dentry.  On the toplevel dentry, you'll flip a flag
in addition to modifying the timestamp.

Later, I'll have to check if the timestamp changed from what I have
remembered in git.  If there is a change, I'll look through the
timestamp of every dentry downwards until I find the modified inode:
certainly much fewer fs calls.  After updating the git index with
fresh information, I'll have to flip the flag on the toplevel
directory again.

>> > This scheme works for arbitrary number of processes interested in recursive
>> > time stamps (only updates of the time stamps get more frequent). What is
>> > somewhat inconvenient is that this only tells you something in the
>> > directory or its subtree changed so you still have to scan all the
>> > directories on the path to modified file. So I'm not sure of how much use
>> > this would be to you.

I think it's a very useful feature to have in general, not just for
git or version control systems.

>> Feel free to write up the details of locking you'll need for that.  It will
>> *not* be fun...

Is this what you mean: What happens if two inodes under the toplevel
directory change nearly simultaneously?  The two propagation threads
will conflict.

>   Actually, it shouldn't be too bad if we don't guarantee we walk exactly
> the path used for modification. Then it is enough to do the same thing as
> following .. from each directory.

I have no idea what this means.

> And for userspace that should be enough because if timestamp update races
> with renames or similar actions somewhere up in the three then these
> operations will generate modification events and update time stamps as
> well. So userspace will notice there was a change.

Do you mean: as long as updating the timestamp is atomic, it doesn't
matter than many threads race to update it (it is guaranteed that
every thread does a successful update)?

> So this part should be doable. But as I wrote before, we might need some
> fs-internal index to allow efficient tracking of what has changed in one
> directory anyway and locking rules / costs for that are non-obvious.

Why does it have to be fs-internal, and not at the VFS layer?  I don't
know what VFS looks like, but of the little I know about btrfs:
There's one global B+ tree where dentry paths are keyed by their CRC32
hashes.  The dentry contains many inodes, and you're worried about
efficiently tracking which inodes have changed.  Why does there have
to be an efficiency concern there?  I suppose multiple inodes'
timestamp changing simultaneously can spawn threads that race to
update the dentry's timestamp.  Why is this challenge different from
the recursive propagation challenge?
--
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: Looking for a mentor

[Ramkumar Ramachandra]

Alexey Shmalko wrote:
> It would be great to participate in the next year GSoC contributing to
> the Linux kernel. For this reason, I have to find a mentor. If someone
> pushes me in the right direction, I'll be happy.

Start sending patches.  There's plenty of low-hanging fruit: just look
around the tree, and try building various components.
--
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] x86/asm: avoid mnemonics without type suffix

[Ramkumar Ramachandra]

1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30)
changed a bunch of btrl/btsl instructions to btr/bts, with the following
justification:

  The inline assembly for the bit operations has been changed to remove
  explicit sizing hints on the instructions, so the assembler will pick
  the appropriate instruction forms depending on the architecture and
  the context.

Unfortunately, GNU as does no such thing, and the AT syntax manual
[1] contains no references to any such inference.  As evidenced by the
following experiment, gas always disambiguates btr/bts to btrl/btsl.
Feed the following input to gas:

  btrl  $1, 0
  btr   $1, 0
  btsl  $1, 0
  bts   $1, 0

Check that btr matches btrl, and bts matches btsl in both cases:

  $ as --32 -a in.s
  $ as --64 -a in.s

To avoid giving readers the illusion of such an inference, and for
clarity, change btr/bts back to btrl/btsl.  Also, llvm-mc refuses to
disambiguate btr/bts automatically.

[1]: http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf

Cc: Jeremy Fitzhardinge 
Cc: Andi Kleen 
Cc: Linus Torvalds 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Eli Friedman 
Cc: Jim Grosbach 
Cc: Stephen Checkoway 
Cc: LLVMdev 
Signed-off-by: Ramkumar Ramachandra 
---
 We discussed this pretty extensively on LLVMDev, but I'm still not
 sure that I haven't missed something.

 arch/x86/include/asm/bitops.h | 16 
 arch/x86/include/asm/percpu.h |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 6dfd019..6ed3d1e 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -67,7 +67,7 @@ set_bit(unsigned int nr, volatile unsigned long *addr)
: "iq" ((u8)CONST_MASK(nr))
: "memory");
} else {
-   asm volatile(LOCK_PREFIX "bts %1,%0"
+   asm volatile(LOCK_PREFIX "btsl %1,%0"
: BITOP_ADDR(addr) : "Ir" (nr) : "memory");
}
 }
@@ -83,7 +83,7 @@ set_bit(unsigned int nr, volatile unsigned long *addr)
  */
 static inline void __set_bit(int nr, volatile unsigned long *addr)
 {
-   asm volatile("bts %1,%0" : ADDR : "Ir" (nr) : "memory");
+   asm volatile("btsl %1,%0" : ADDR : "Ir" (nr) : "memory");
 }
 
 /**
@@ -104,7 +104,7 @@ clear_bit(int nr, volatile unsigned long *addr)
: CONST_MASK_ADDR(nr, addr)
: "iq" ((u8)~CONST_MASK(nr)));
} else {
-   asm volatile(LOCK_PREFIX "btr %1,%0"
+   asm volatile(LOCK_PREFIX "btrl %1,%0"
: BITOP_ADDR(addr)
: "Ir" (nr));
}
@@ -126,7 +126,7 @@ static inline void clear_bit_unlock(unsigned nr, volatile 
unsigned long *addr)
 
 static inline void __clear_bit(int nr, volatile unsigned long *addr)
 {
-   asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
+   asm volatile("btrl %1,%0" : ADDR : "Ir" (nr));
 }
 
 /*
@@ -198,7 +198,7 @@ static inline int test_and_set_bit(int nr, volatile 
unsigned long *addr)
 {
int oldbit;
 
-   asm volatile(LOCK_PREFIX "bts %2,%1\n\t"
+   asm volatile(LOCK_PREFIX "btsl %2,%1\n\t"
 "sbb %0,%0" : "=r" (oldbit), ADDR : "Ir" (nr) : "memory");
 
return oldbit;
@@ -230,7 +230,7 @@ static inline int __test_and_set_bit(int nr, volatile 
unsigned long *addr)
 {
int oldbit;
 
-   asm("bts %2,%1\n\t"
+   asm("btsl %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit), ADDR
: "Ir" (nr));
@@ -249,7 +249,7 @@ static inline int test_and_clear_bit(int nr, volatile 
unsigned long *addr)
 {
int oldbit;
 
-   asm volatile(LOCK_PREFIX "btr %2,%1\n\t"
+   asm volatile(LOCK_PREFIX "btrl %2,%1\n\t"
 "sbb %0,%0"
 : "=r" (oldbit), ADDR : "Ir" (nr) : "memory");
 
@@ -276,7 +276,7 @@ static inline int __test_and_clear_bit(int nr, volatile 
unsigned long *addr)
 {
int oldbit;
 
-   asm volatile("btr %2,%1\n\t"
+   asm volatile("btrl %2,%1\n\t"
 "sbb %0,%0"
 : "=r" (oldbit), ADDR
 : "Ir" (nr));
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 0da5200..fda54c9 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -490,7 +490,7 @@ do {
\
 #define x86_test_and_clear_bit_percpu(bit, var)  

Re: [PATCH] x86/asm: avoid mnemonics without type suffix

[Ramkumar Ramachandra]

Linus Torvalds wrote:
>>   btrl  $1, 0
>>   btr   $1, 0
>>   btsl  $1, 0
>>   bts   $1, 0
>
> What the heck is that supposed to show?

I was trying to show a reduced case where gas doesn't complain, but
llvm-mc does.  Try compiling this with llvm-mc, and you'll get:

.text
btrl$1, 0
in.s:2:1: error: ambiguous instructions require an explicit suffix
  (could be 'btrw', 'btrl', or 'btrq')
btr $1, 0
^
btsl$1, 0
in.s:4:1: error: ambiguous instructions require an explicit suffix
  (could be 'btsw', 'btsl', or 'btsq')
bts $1, 0
^

Obviously, I misunderstood something major and screwed up the commit message.

> int main(int argc, char **argv)
> {
>   asm("bt %1,%0":"=m" (**argv): "a" (argc));
>   asm("bt %1,%0":"=m" (**argv): "a" ((unsigned long)(argc)));
> }

Right, so in:

int main(int argc, char **argv)
{
  asm("bts %1,%0":"=m" (**argv): "r" (argc));
  asm("btsl %1,%0":"=m" (**argv): "r" (argc));
  asm("btr %1,%0":"=m" (**argv): "r" ((unsigned long)(argc)));
  asm("btrq %1,%0":"=m" (**argv): "r" ((unsigned long)(argc)));
}

bts disambiguates to btsl, and btr disambiguates to btrq, as
advertised.  Is it dependent on whether I have a 32-bit machine or
64-bit machine, or just on the operand lengths?

Either way, this is not a very enlightening example, because clang
also compiles this fine, and doesn't complain about any ambiguity.  To
see the ambiguity I'm talking about, try to compile linux.git with
clang; I'll paste one error:

arch/x86/include/asm/bitops.h:129:15: error: ambiguous instructions
  require an explicit suffix (could be 'btrw', 'btrl', or 'btrq')
asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
 ^
:1:2: note: instantiated into assembly here
btr $0,(%rsi)
^

Since nr is an int, and ADDR is *(volatile long *), this should
disambiguate to btrl, right?  Any clue why clang is complaining?
--
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/asm: avoid mnemonics without type suffix

[Ramkumar Ramachandra]

Linus Torvalds wrote:
> Ok. So your commit message and explanation was pure and utter tripe,
> and the real reason you want this is that llvm-mc is broken.
>
> Please fix llvm-mc instead, ok? If the intent of llvm is to be
> compatible with the gnu compiler tools, then it should do that. Plus
> the gas behavior is clearly superior, so why not just improve the llvm
> toolchain to match those improved semantics?

Yep.  I started the discussion on LLVMDev, and posted patches [1].
>From the discussions on the list, many of the devs are claiming that
LLVM is "correct" and that linux.git needs to be patched.  I'm not
taking sides; I just want a solution to the problem.

[1]: The archive is broken, but here are some pieces:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130708/180968.html
--
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] arch/um: make it work with defconfig and x86_64

[Ramkumar Ramachandra]

Ping?

Does this patch look okay?

Thanks.

On Fri, Jul 5, 2013 at 4:15 AM, Ramkumar Ramachandra  wrote:
> arch/um/defconfig only lists one default configuration, and that applies
> only to the i386 architecture.  Replace it with two files:
>
>   i386_defconfig and x86_64_defconfig
>
> The build scripts now require two updates:
>
> 1. um's Kconfig (arch/x86/um/Kconfig) should specify an ARCH_DEFCONFIG
>section explicitly pointing to these scripts if the required
>variables are set.  Take care to remove the DEFCONFIG_LIST section
>defined in the included file arch/um/Kconfig.common.
>
> 2. um's Makefile (arch/um/Makefile) should set KBUILD_DEFCONFIG properly
>for the top-level Makefile to pick up.  Copy the logic in
>arch/x86/Makefile to properly pick the defconfig file depending on
>the actual architecture; except we're working with $SUBARCH here,
>instead of $ARCH.
>
> Now, you can do:
>
>   $ ARCH=um make defconfig
>   $ ARCH=um make
>
> and successfully build User-Mode Linux on an x86_64 box in default
> configuration.
>
> Cc: Richard Weinberger 
> Cc: Jeff Dike 
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  arch/um/Kconfig.common  |   5 -
>  arch/um/Makefile|  11 ++
>  arch/um/{defconfig => configs/i386_defconfig}   | 209 +---
>  arch/um/{defconfig => configs/x86_64_defconfig} | 250 
> +++-
>  arch/x86/um/Kconfig |   5 +
>  5 files changed, 306 insertions(+), 174 deletions(-)
>  copy arch/um/{defconfig => configs/i386_defconfig} (86%)
>  rename arch/um/{defconfig => configs/x86_64_defconfig} (83%)
>
> diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
> index bceee66..10129a5 100644
> --- a/arch/um/Kconfig.common
> +++ b/arch/um/Kconfig.common
> @@ -1,8 +1,3 @@
> -config DEFCONFIG_LIST
> -   string
> -   option defconfig_list
> -   default "arch/$ARCH/defconfig"
> -
>  config UML
> bool
> default y
> diff --git a/arch/um/Makefile b/arch/um/Makefile
> index 133f7de..48d92bb 100644
> --- a/arch/um/Makefile
> +++ b/arch/um/Makefile
> @@ -6,6 +6,17 @@
>  # Licensed under the GPL
>  #
>
> +# select defconfig based on actual architecture
> +ifeq ($(SUBARCH),x86)
> +  ifeq ($(shell uname -m),x86_64)
> +KBUILD_DEFCONFIG := x86_64_defconfig
> +  else
> +KBUILD_DEFCONFIG := i386_defconfig
> +  endif
> +else
> +KBUILD_DEFCONFIG := $(SUBARCH)_defconfig
> +endif
> +
>  ARCH_DIR := arch/um
>  OS := $(shell uname -s)
>  # We require bash because the vmlinux link and loader script cpp use bash
> diff --git a/arch/um/defconfig b/arch/um/configs/i386_defconfig
> similarity index 86%
> copy from arch/um/defconfig
> copy to arch/um/configs/i386_defconfig
> index 08107a7..995aecd 100644
> --- a/arch/um/defconfig
> +++ b/arch/um/configs/i386_defconfig
> @@ -1,6 +1,6 @@
>  #
>  # Automatically generated file; DO NOT EDIT.
> -# User Mode Linux/i386 3.3.0 Kernel Configuration
> +# User Mode Linux/x86 3.10.0 Kernel Configuration
>  #
>  CONFIG_DEFCONFIG_LIST="arch/$ARCH/defconfig"
>  CONFIG_UML=y
> @@ -11,7 +11,6 @@ CONFIG_LOCKDEP_SUPPORT=y
>  # CONFIG_STACKTRACE_SUPPORT is not set
>  CONFIG_GENERIC_CALIBRATE_DELAY=y
>  CONFIG_GENERIC_BUG=y
> -CONFIG_GENERIC_CLOCKEVENTS=y
>  CONFIG_HZ=100
>
>  #
> @@ -47,25 +46,17 @@ CONFIG_M686=y
>  # CONFIG_MATOM is not set
>  # CONFIG_X86_GENERIC is not set
>  CONFIG_X86_INTERNODE_CACHE_SHIFT=5
> -CONFIG_X86_CMPXCHG=y
>  CONFIG_X86_L1_CACHE_SHIFT=5
> -CONFIG_X86_XADD=y
>  CONFIG_X86_PPRO_FENCE=y
> -CONFIG_X86_WP_WORKS_OK=y
> -CONFIG_X86_INVLPG=y
> -CONFIG_X86_BSWAP=y
> -CONFIG_X86_POPAD_OK=y
>  CONFIG_X86_USE_PPRO_CHECKSUM=y
>  CONFIG_X86_TSC=y
>  CONFIG_X86_CMPXCHG64=y
>  CONFIG_X86_CMOV=y
>  CONFIG_X86_MINIMUM_CPU_FAMILY=5
>  CONFIG_CPU_SUP_INTEL=y
> -CONFIG_CPU_SUP_CYRIX_32=y
>  CONFIG_CPU_SUP_AMD=y
>  CONFIG_CPU_SUP_CENTAUR=y
>  CONFIG_CPU_SUP_TRANSMETA_32=y
> -CONFIG_CPU_SUP_UMC_32=y
>  CONFIG_UML_X86=y
>  # CONFIG_64BIT is not set
>  CONFIG_X86_32=y
> @@ -77,30 +68,28 @@ CONFIG_ARCH_HAS_SC_SIGNALS=y
>  CONFIG_ARCH_REUSE_HOST_VSYSCALL_AREA=y
>  CONFIG_GENERIC_HWEIGHT=y
>  # CONFIG_STATIC_LINK is not set
> -CONFIG_SELECT_MEMORY_MODEL=y
> -CONFIG_FLATMEM_MANUAL=y
>  CONFIG_FLATMEM=y
>  CONFIG_FLAT_NODE_MEM_MAP=y
> +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
>  CONFIG_PAGEFLAGS_EXTENDED=y
>  CONFIG_SPLIT_PTLOCK_CPUS=4
>  # CONFIG_COMPACTION is not set
>  # CONFIG_PHYS_ADDR_T_64BIT is not set
>  CONFIG_ZONE_DMA_FLAG=0
> -CONFIG_VIR

Re: [PATCH 0/7] Minor perf completion improvements

[Ramkumar Ramachandra]

Ping?

Does this series look alright?

On Thu, Jul 4, 2013 at 6:11 PM, Ramkumar Ramachandra  wrote:
> Hi,
>
> So I just started using perf, and noticed the accompanying completion
> script. Having dabbled with git.git's completion script a bit, I
> thought I should contribute what I learnt from it.
>
> [6/7] is the meat of the series, and the preceding patches work
> towards the same goal: to strip dependency on the bash-completion
> package.
>
> Thanks.
>
> Ramkumar Ramachandra (7):
>   perf completion: don't dictate perf install location
>   perf completion: update __ltrim_colon_completions
>   perf completion: strip dependency on _filedir
>   perf completion: modernize style
>   perf completion: strip function_exists ()
>   perf completion: strip dependency on bash-completion
>   perf completion: use more comp words
>
>  tools/perf/bash_completion | 110 
> +++--
>  1 file changed, 87 insertions(+), 23 deletions(-)
>
> --
> 1.8.3.1.643.gebeea52.dirty
>
--
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: [RESEND] The initmpfs patches.

[Ramkumar Ramachandra]

Rob Landley wrote:
> (Balsa is such an incompetent email client I wrote a python script to do
> this via raw smtp, and I'm always convinced it's going to screw up the send.
> But I think I've got it debugged now...)

Use the tried-and-tested git-send-email.perl, perhaps?
--
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/

[QUERY] User-Mode Linux and /dev/tty*

[Ramkumar Ramachandra]

Hi,

So, I was trying to boot User-Mode Linux with a modern rootfs with
systemd on it, and found that it wouldn't present me a prompt.  I dug
further, and found out that getty is not able to open /dev/tty1; I
then tried the console-getty.service (which uses /dev/console), and it
worked.  The reason it doesn't work out of the box is that systemd is
not able to figure out whether or not a virtual console subsystem is
present: /dev/tty0 is present for some reason (although I'm not sure
it's a virtual console), and this confuses systemd.

So, my question is: does um Linux have a virtual console subsystem?
If so, then why doesn't it seem to work?  If not, why does /dev/tty0
exist?

Thanks.
--
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: [QUERY] User-Mode Linux and /dev/tty*

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> UML does not have CONFIG_VT.

Not sure what this means.

> But recent systemd versions can deal with that.

Nope, running systemd HEAD.  I only recently figured out how to detect
that um Linux is running [1].

[1]: https://github.com/systemd/systemd/commit/7080ea16
--
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: [QUERY] User-Mode Linux and /dev/tty*

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> UML does not have virtual consoles.

Then why do I see this on my UML box?

# ls /dev/tty* | wc -l
113

Why is it creating unusable devices?  Is drivers/tty.c responsible for
this?  What is it exactly?

> I'm not running HEAD, but opensuse 12.3 (with systemd) works on UML.

Also, what's with all the

   xterm_open : run_helper failed, errno = 2

messages?  (I installed xterm, but it wasn't very enlightening)
How is drivers/xterm.c supposed to work?  And what is mconsole?
--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Avoid creating lots of bogus devices nodes like /dev/tty* (since
User-Mode Linux does not have virtual consoles.

Cc: Richard Weinberger 
Cc: Jeff Dike 
Signed-off-by: Ramkumar Ramachandra 
---
 Applies on top of the patch I posted earlier.

 arch/um/configs/i386_defconfig   | 3 +--
 arch/um/configs/x86_64_defconfig | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/um/configs/i386_defconfig b/arch/um/configs/i386_defconfig
index 995aecd..93f4f97 100644
--- a/arch/um/configs/i386_defconfig
+++ b/arch/um/configs/i386_defconfig
@@ -293,8 +293,7 @@ CONFIG_HOSTAUDIO=m
 # Generic Driver Options
 #
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_DEVTMPFS is not set
 CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
diff --git a/arch/um/configs/x86_64_defconfig b/arch/um/configs/x86_64_defconfig
index f2c6123..17650a6 100644
--- a/arch/um/configs/x86_64_defconfig
+++ b/arch/um/configs/x86_64_defconfig
@@ -285,8 +285,7 @@ CONFIG_HOSTAUDIO=m
 # Generic Driver Options
 #
 CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_DEVTMPFS is not set
 CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
-- 
1.8.3.3.754.g9c3c367

--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> If you don't want devtmpfs, just disable it in your config.

I don't understand: is this not a good default?  Why is creating bogus
devices, confusing systemd, and making um Linux hard to boot
desirable?
--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> Why does this confuse systemd? systemd has also a dependency on devtmpfs.

See getty@.service, which is a dependency of getty.target:

  # On systems without virtual consoles, don't start any getty. (Note
  # that serial gettys are covered by serial-getty@.service, not this
  # unit
  ConditionPathExists=/dev/tty0

No, systemd does not have a hard dependency on devtmpfs.  See
src/getty-generator/getty-generator.c:

  if (detect_container(NULL) > 0) {
  log_debug("Automatically adding console shell.");

  if (add_symlink("console-getty.service", "console-getty.service") < 0)
  r = EXIT_FAILURE;

  /* Don't add any further magic if we are in a container */
  goto finish;
  }

I can add a rule for detect_vm() and id = "uml" here, so that um Linux
runs console-getty.service out-of-the-box.  After I do that,
systemd-vconsole-setup.service will fail precisely because systemd
sees a /dev/tty0 and gets confused.
--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> No, systemd does not have a hard dependency on devtmpfs.

Wait, let me double-check that.
--
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/7] perf completion: modernize style

[Ramkumar Ramachandra]

Arnaldo Carvalho de Melo wrote:
> Huh? Why would this be more "modern", if both are equivalent, I think
> applying the same rules as we have for C code applies here.

It's the prevalent style in git.git, and I figured that it was picked
up from linux.git but didn't check.  Drop this part otherwise.

Thanks.
--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra wrote:
>> No, systemd does not have a hard dependency on devtmpfs.
>
> Wait, let me double-check that.

Sorry about the stupidity; devtmpfs is very much a hard dependency.  I
just realized that CONFIG_VT is on, and can't be turned off (!).  See
drivers/tty/Kconfig:

  config VT
  bool "Virtual terminal" if EXPERT
  depends on !S390 && !UML

Wait, shouldn't it be always off then?

*scratches head*
--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> BTW: I'll not apply any patch to the kernel if the issue can easily
> fixed in user space, that's the major reason for my NAK.

I was just asking for good defaults; I want um Linux to work
out-of-the-box.  There's really no point in creating bogus devices in
/dev, and make life unnecessarily hard for user-space applications:
instead of checking for existence, they'd have to check that all the
devices work.  I doubt systemd will accept such a patch, just to bend
over backwards and support um.
--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Al Viro wrote:
> As for the devices, they are *not* bogus.  RTFM, already.
> Documentation/virtual/uml/UserModeLinux-HOWTO.txt, if you can't be bothered
> to say git grep UML Documentation/ and find where it on your own.  The
> relevant section is called "Setting up serial lines and consoles".
> Seriously, it's not as if the documentation didn't exist or had been
> hard to find...

Yes; I've been trying to decipher the con thing for some time now.

> FWIW, default config is rather annoying - 6 xterms spawned and associated
> with /dev/tty[1-6].  con0=fd:0,fd:1 con=pts mentioned in the HOWTO would,
> IMO, make for much saner default.

Leave aside the fact that I could not find the uml-utils upstream [1],
and didn't have a /uml/port-helper to connect the xterms for a second;
I didn't even understand what was supposed to happen.  Why do we spawn
xterms, and attach to the host's /dev/tty*?  So far, I just used
/dev/console inside my existing tmux session in urxvt, and it seems to
work fine.

> No comments on systemd behaviour - take that with LP and his crowd.  They
> may or may not be confused by /dev/tty1 not being a virtual console.

>From my brief discussion with Lennart, he's just following what
Documentation/devices.txt says: /dev/tty* are virtual consoles.  If um
is making some sort of exception for good reason, I'm sure systemd can
accommodate it.

> One
> practical issue is the lack of VT102 emulation;

This detail is not at all clear from the Documentation.  I spent a lot
of time trying to figure out why systemd wasn't able to getty on
/dev/tty1.

> TERM=linux when logged
> in on those is not right - you want either TERM=xterm (for xterms) or
> TERM=screen (when accessing pts-associated ones with screen /dev/pts/n),
> etc.  In any case, it's a dumb serial line as far as the guest kernel
> is concerned - all terminal emulation is going to happen elsewhere (xterms
> running on host and interpreting escape sequences from guest userland,
> etc.)

Hm, what does $TERM have to do with all this?

[1]: A fabulously empty git repository here:
sourceforge.net/p/user-mode-linux/git/ref/master/
--
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] um/configs: don't use devtmpfs in defconfig

[Ramkumar Ramachandra]

Richard Weinberger wrote:
> http://user-mode-linux.sourceforge.net/downloads.html

I found a uml_utilities_20070815.tar.bz2.  2007, seriously?  Is there
no interest in maintaining it?
--
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: [RESEND] The initmpfs patches.

[Ramkumar Ramachandra]

Rob Landley wrote:
> Is this script of yours any use for patches that aren't, and never were, in
> git? (Given that it's not in the kernel tree, I'm guessing "no".)

It's part of git.git.  And yes, it works with plain mbox files
(especially those generated by `git format-patch`).
--
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: [ATTEND] How to act on LKML

[Ramkumar Ramachandra]

Sarah Sharp wrote:
> I do smile often in email. :)  And be sad. :( And be apologetic. :-/
> Smug. ^~^  Angry. >:[  Sarcastic. ;)  Trolling/crazy. 8)  D'oh. (>.<)
> Worried. (>_>);  Disappointed. (-_-)  Kitty! =^_^=  Meow!
>
> Be creative.  There are ways of expressing emotion without cussing.

Personally, I think the whole issue of swearing on-list is taken way
too seriously [1].  There are many ways of expressing emotion;
considering one such form "unprofessional" is just a form of
suffocation.  Members of the mailing list automatically pick up on the
influential styles (i.e. the styles of the active participants and
effective communicators).  If you think your style is "better",
there's exactly one way to verify the claim: you participate actively;
your style will automatically rub off on the others if it is shown to
be effective.

[1]: http://youtu.be/7raS7hmLkAA
--
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: [Ksummit-2013-discuss] [ATTEND] How to act on LKML

[Ramkumar Ramachandra]

Sarah Sharp wrote:
> https://picasaweb.google.com/116960357493251979546/Trolls#5901298464591248626
> https://picasaweb.google.com/116960357493251979546/Trolls#5901288095984358098
>
> On my blog, here's some choice comments, mostly asking me to quit kernel
> development, along with more than a few misogynist comments:

So it's a publicity stunt then.  That is the only rational
explanation, because the alternative explanation is that you're trying
to tame the internet ;)

Another flash in the pan: this whole event (and you) will be erased
from everyone's memories in a few weeks.  Okay, maybe a few months if
you get fired from SendGrid.

You're better than that.  Think calmly, and focus your attention on
making a long-term impact.  Hint: it's not going to happen by arguing
endlessly about the same thing.
--
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/7] perf completion: modernize style

[Ramkumar Ramachandra]

Arnaldo Carvalho de Melo wrote:
> Can you check how is this in the current perf/core branch so that we can
> move forward while I process some other patches?

This series (except this part) was merged into perf/completion of
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux 3 weeks ago,
so I'm not sure what perf/core has to do with it.

To answer your question about prevalent style:

  $ git grep "[^ ]()" -- \*.sh

returns many more results than

  $ git grep " ()" -- \*.sh

This is different from what you will see in git.git.

Anyway, consistent style is important in shell scripts mainly because
we don't have semantic parsers and have to rely on it being grep'able
to find something. So, yeah: perf/completion is good as it is.

Thanks.
--
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] virtio tools: use ansi versions of asm and volatile

[Ramkumar Ramachandra]

Rusty Russell wrote:
> Ramkumar Ramachandra  writes:
>> asm and volatile are provided for backward compatibility; use the ansi
>> versions __asm__ and __volatile__.
>
> Really?  I don't see that in the gcc documentation.  In fact, I didn't
> know __volatile__ at all:

Try compiling the program with `gcc -ansi`, and you'll see that "asm"
and "volatile" are undeclared. The motivation for my patch comes from
barrier() being declared differently in compiler-gcc.h.

However, the tree is polluted with the non-ansi versions anyway;
compilers will continue to support them for decades. So, I'd request
you to drop the patch.

Thanks.
--
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: [INCOMPLETE PATCH 4/4] perf diff: give Ratio column an appropriate color

[Ramkumar Ramachandra]

Jiri Olsa wrote:
> On Thu, Nov 21, 2013 at 08:03:47PM +0530, Ramkumar Ramachandra wrote:
>> In
>>
>>   $ perf diff -c ratio
>>
>> color the Ratio column using percent_color_snprintf().
>
> why is there 'INCOMPLETE' in the subject?

As explained in the segment below the diffstat:

The incomplete bit is marked using a TODO; removing two trailing '%'
symbols doesn't seem to work. Can someone please tell me how to fix
this problem?
--
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 2/4] perf diff: give Delta column an appropriate color

[Ramkumar Ramachandra]

Jiri Olsa wrote:
> this patch changes the diff output for 'perf diff'
>
> file '1' - old perf
> file '2' - your change
>
> I expected only the difference would be only color
> not numbers.

Oh, sorry; I forgot about the threshold completely. I'll submit
another iteration with a fresh [4/4] once you tell me how to fix that.
--
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 v2 1/5] perf diff: don't compute Delta if he->dummy

[Ramkumar Ramachandra]

Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 3b67ea2..79e0448 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -792,6 +792,9 @@ hpp__entry_pair(struct hist_entry *he, struct hist_entry 
*pair,
 
switch (idx) {
case PERF_HPP_DIFF__DELTA:
+   if (he->dummy)
+   break;
+
if (pair->diff.computed)
diff = pair->diff.period_ratio_delta;
else
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v2 0/5] More color in 'perf diff'

[Ramkumar Ramachandra]

Hi,

This round fixes two problems in the last round:

- In [2/5], the color version includes the 0.01 threshold that was
  present in the non-color version (thanks to Jiri).

- In [4/5], the trailing '%' is gone (maked as a TODO in the last
  round).

and introduces one new patch for wdiff: [5/5].

Thanks.

Ramkumar Ramachandra (5):
  perf diff: don't compute Delta if he->dummy
  perf diff: color the Delta column
  perf diff: generalize hpp__color_delta for -c
  perf diff: color the Ratio column
  perf diff: color the Weighted Diff column

 tools/perf/builtin-diff.c | 109 +-
 1 file changed, 108 insertions(+), 1 deletion(-)

-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v2 3/5] perf diff: generalize hpp__color_delta for -c

[Ramkumar Ramachandra]

Generalize the function so that we can accommodate all three comparison
methods: delta, ratio, and wdiff.

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 47 +--
 1 file changed, 37 insertions(+), 10 deletions(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 84d5f2d..a54736c 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -769,33 +769,60 @@ static int hpp__entry_baseline(struct hist_entry *he, 
char *buf, size_t size)
return ret;
 }
 
-static int hpp__color_delta(struct perf_hpp_fmt *fmt,
-   struct perf_hpp *hpp, struct hist_entry *he)
+static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he,
+   int comparison_method)
 {
struct diff_hpp_fmt *dfmt =
container_of(fmt, struct diff_hpp_fmt, fmt);
struct hist_entry *pair = get_pair_fmt(he, dfmt);
-   double percent;
+   double delta;
char pfmt[20] = " ";
 
if (!pair)
goto dummy_print;
if (pair->diff.computed)
-   percent = pair->diff.period_ratio_delta;
+   switch (comparison_method) {
+   case COMPUTE_DELTA:
+   delta = pair->diff.period_ratio_delta;
+   break;
+   default:
+   BUG_ON(1);
+   }
else
-   percent = compute_delta(he, pair);
+   switch (comparison_method) {
+   case COMPUTE_DELTA:
+   delta = compute_delta(he, pair);
+   break;
+   default:
+   BUG_ON(1);
+   }
 
-   if (!he->dummy && fabs(percent) >= 0.01) {
-   scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
-   return color_snprintf(hpp->buf, hpp->size,
-   percent > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
-   pfmt, percent);
+   if (!he->dummy) {
+   switch (comparison_method) {
+   case COMPUTE_DELTA:
+   if (fabs(delta) < 0.01)
+   goto dummy_print;
+   scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width 
- 1);
+   return color_snprintf(hpp->buf, hpp->size,
+   delta > 0 ? PERF_COLOR_GREEN : 
PERF_COLOR_RED,
+   pfmt, delta);
+   break;
+   default:
+   BUG_ON(1);
+   }
} else
 dummy_print:
return scnprintf(hpp->buf, hpp->size, "%*s",
dfmt->header_width, pfmt);
 }
 
+static int hpp__color_delta(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_DELTA);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v2 2/5] perf diff: color the Delta column

[Ramkumar Ramachandra]

Color the numbers in the Delta column either green or red depending on
whether the number is positive or negative.

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 79e0448..84d5f2d 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -769,6 +769,33 @@ static int hpp__entry_baseline(struct hist_entry *he, char 
*buf, size_t size)
return ret;
 }
 
+static int hpp__color_delta(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   struct diff_hpp_fmt *dfmt =
+   container_of(fmt, struct diff_hpp_fmt, fmt);
+   struct hist_entry *pair = get_pair_fmt(he, dfmt);
+   double percent;
+   char pfmt[20] = " ";
+
+   if (!pair)
+   goto dummy_print;
+   if (pair->diff.computed)
+   percent = pair->diff.period_ratio_delta;
+   else
+   percent = compute_delta(he, pair);
+
+   if (!he->dummy && fabs(percent) >= 0.01) {
+   scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
+   return color_snprintf(hpp->buf, hpp->size,
+   percent > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
+   pfmt, percent);
+   } else
+dummy_print:
+   return scnprintf(hpp->buf, hpp->size, "%*s",
+   dfmt->header_width, pfmt);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -943,8 +970,16 @@ static void data__hpp_register(struct data__file *d, int 
idx)
fmt->entry  = hpp__entry_global;
 
/* TODO more colors */
-   if (idx == PERF_HPP_DIFF__BASELINE)
+   switch (idx) {
+   case PERF_HPP_DIFF__BASELINE:
fmt->color = hpp__color_baseline;
+   break;
+   case PERF_HPP_DIFF__DELTA:
+   fmt->color = hpp__color_delta;
+   break;
+   default:
+   break;
+   }
 
init_header(d, dfmt);
perf_hpp__column_register(fmt);
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v2 4/5] perf diff: color the Ratio column

[Ramkumar Ramachandra]

In

  $ perf diff -c ratio

color the Ratio column using percent_color_snprintf().

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index a54736c..be2550c 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -786,6 +786,9 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
case COMPUTE_DELTA:
delta = pair->diff.period_ratio_delta;
break;
+   case COMPUTE_RATIO:
+   delta = pair->diff.period_ratio;
+   break;
default:
BUG_ON(1);
}
@@ -794,6 +797,9 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
case COMPUTE_DELTA:
delta = compute_delta(he, pair);
break;
+   case COMPUTE_RATIO:
+   delta = compute_ratio(he, pair);
+   break;
default:
BUG_ON(1);
}
@@ -808,6 +814,11 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
delta > 0 ? PERF_COLOR_GREEN : 
PERF_COLOR_RED,
pfmt, delta);
break;
+   case COMPUTE_RATIO:
+   scnprintf(pfmt, 20, "%%%d.6f", dfmt->header_width);
+   return percent_color_snprintf(hpp->buf, hpp->size,
+   pfmt, delta);
+   break;
default:
BUG_ON(1);
}
@@ -823,6 +834,12 @@ static int hpp__color_delta(struct perf_hpp_fmt *fmt,
return __hpp__color_compare(fmt, hpp, he, COMPUTE_DELTA);
 }
 
+static int hpp__color_ratio(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_RATIO);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -1004,6 +1021,9 @@ static void data__hpp_register(struct data__file *d, int 
idx)
case PERF_HPP_DIFF__DELTA:
fmt->color = hpp__color_delta;
break;
+   case PERF_HPP_DIFF__RATIO:
+   fmt->color = hpp__color_ratio;
+   break;
default:
break;
}
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v2 5/5] perf diff: color the Weighted Diff column

[Ramkumar Ramachandra]

In

  $ perf diff -c wdiff:M,N

color the numbers in the Weighted Diff column either green or red,
depending on whether the number is positive or negative.

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index be2550c..f3f5d8e 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -777,6 +777,7 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
container_of(fmt, struct diff_hpp_fmt, fmt);
struct hist_entry *pair = get_pair_fmt(he, dfmt);
double delta;
+   s64 wdiff;
char pfmt[20] = " ";
 
if (!pair)
@@ -789,6 +790,9 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
case COMPUTE_RATIO:
delta = pair->diff.period_ratio;
break;
+   case COMPUTE_WEIGHTED_DIFF:
+   wdiff = pair->diff.wdiff;
+   break;
default:
BUG_ON(1);
}
@@ -800,6 +804,9 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
case COMPUTE_RATIO:
delta = compute_ratio(he, pair);
break;
+   case COMPUTE_WEIGHTED_DIFF:
+   wdiff = compute_wdiff(he, pair);
+   break;
default:
BUG_ON(1);
}
@@ -819,6 +826,12 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
return percent_color_snprintf(hpp->buf, hpp->size,
pfmt, delta);
break;
+   case COMPUTE_WEIGHTED_DIFF:
+   scnprintf(pfmt, 20, "%%14ld", dfmt->header_width);
+   return color_snprintf(hpp->buf, hpp->size,
+   wdiff > 0 ? PERF_COLOR_GREEN : 
PERF_COLOR_RED,
+   pfmt, wdiff);
+   break;
default:
BUG_ON(1);
}
@@ -840,6 +853,12 @@ static int hpp__color_ratio(struct perf_hpp_fmt *fmt,
return __hpp__color_compare(fmt, hpp, he, COMPUTE_RATIO);
 }
 
+static int hpp__color_wdiff(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_WEIGHTED_DIFF);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -1024,6 +1043,9 @@ static void data__hpp_register(struct data__file *d, int 
idx)
case PERF_HPP_DIFF__RATIO:
fmt->color = hpp__color_ratio;
break;
+   case PERF_HPP_DIFF__WEIGHTED_DIFF:
+   fmt->color = hpp__color_wdiff;
+   break;
default:
break;
}
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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: [INCOMPLETE PATCH 4/4] perf diff: give Ratio column an appropriate color

[Ramkumar Ramachandra]

Jiri Olsa wrote:
>>  The incomplete bit is marked using a TODO; removing two trailing '%'
>>  symbols doesn't seem to work. Can someone please tell me how to fix
>>  this problem?
>
> aah here it is..

I fixed it and sent another iteration.
--
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 3/5] perf diff: generalize hpp__color_delta for -c

[Ramkumar Ramachandra]

Jiri Olsa wrote:
> I think it'd be better to have just one switch for
> comparison_method and do all the processing within

Okay, will fix in the next iteration.
--
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 3/5] perf diff: generalize hpp__color_delta for -c

[Ramkumar Ramachandra]

Jiri Olsa wrote:
>>   if (!pair)
>>   goto dummy_print;
>>   if (pair->diff.computed)
>> - percent = pair->diff.period_ratio_delta;
>> + switch (comparison_method) {
>> + case COMPUTE_DELTA:
>> + delta = pair->diff.period_ratio_delta;
>> + break;
>> + default:
>> + BUG_ON(1);
>> + }
>>   else
>> - percent = compute_delta(he, pair);
>> + switch (comparison_method) {
>> + case COMPUTE_DELTA:
>> + delta = compute_delta(he, pair);
>> + break;
>> + default:
>> + BUG_ON(1);
>> + }
>>
>> - if (!he->dummy && fabs(percent) >= 0.01) {
>> - scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
>> - return color_snprintf(hpp->buf, hpp->size,
>> - percent > 0 ? PERF_COLOR_GREEN : 
>> PERF_COLOR_RED,
>> - pfmt, percent);
>> + if (!he->dummy) {
>
> isn't this check superfluous because of the above (!pair) check?

>From builtin-diff.c:get_pair_data(), we see that `pair' is one of the
pairs in he->pairs. he->dummy is set in
util/hist.c:hists__add_dummy_entry() which is called only when he
doesn't have pairs (util/hist.c:942). Wait, couldn't
util/hist.c:hists__add_dummy_entry() also have returned NULL in the
case when he is NULL? But  __hpp__color_compare wouldn't have been
called with a NULL he in the first place. So yeah, the check is
redundant although it wasn't immediately obvious to me.

Thanks.
--
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 2/5] perf diff: color the Delta column

[Ramkumar Ramachandra]

Jiri Olsa wrote:
>> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
>> index 79e0448..84d5f2d 100644
>> --- a/tools/perf/builtin-diff.c
>> +++ b/tools/perf/builtin-diff.c
>> @@ -769,6 +769,33 @@ static int hpp__entry_baseline(struct hist_entry *he, 
>> char *buf, size_t size)
>>   return ret;
>>  }
>>
>> +static int hpp__color_delta(struct perf_hpp_fmt *fmt,
>> + struct perf_hpp *hpp, struct hist_entry *he)
>> +{
>> + struct diff_hpp_fmt *dfmt =
>> + container_of(fmt, struct diff_hpp_fmt, fmt);
>> + struct hist_entry *pair = get_pair_fmt(he, dfmt);
>> + double percent;
>> + char pfmt[20] = " ";
>> +
>> + if (!pair)
>> + goto dummy_print;
>
> same comment here ^^^ as for previous patch

Hm? The comment on the previous patch pertained to printing the delta
if he->dummy was set (ie. if `he' doesn't have any pairs). This
statement is analogous to the logic in __hpp__entry_global(): if
(!pair), then the next line checking pair->diff.computed will segfault
without this check.
--
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 1/5] perf diff: don't compute Delta if he->dummy

[Ramkumar Ramachandra]

Jiri Olsa wrote:
>> diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
>> index 3b67ea2..79e0448 100644
>> --- a/tools/perf/builtin-diff.c
>> +++ b/tools/perf/builtin-diff.c
>> @@ -792,6 +792,9 @@ hpp__entry_pair(struct hist_entry *he, struct hist_entry 
>> *pair,
>>
>>   switch (idx) {
>>   case PERF_HPP_DIFF__DELTA:
>> + if (he->dummy)
>> + break;
>> +
>
> the reason I disabled the computation for dummy pairs was
> that the number (ratio and weighted diff) would not make much
> sense (to me) without the real pair
>
> but within the dummy delta column we actually see the compared
> file % overheader which is helpfull, even if there's no real pair
> in the baseline

Wait a minute. Doesn't your comment on [3/5] apply here too?
__hpp__entry_global() computes and checks `pair' before calling
hpp__entry_pair(). If he->dummy is set, it means that `he' doesn't
have any pairs: which means that hpp_entry_pair() wouldn't have been
called by __hpp_entry_global() in the first place. So aren't the
he->dummy checks in the RATIO and WEIGHTED_DIFF case redundant?
--
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 3/5] perf diff: generalize hpp__color_delta for -c

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> Jiri Olsa wrote:
>>>   if (!pair)
>>>   goto dummy_print;
>>>   if (pair->diff.computed)
>>> - percent = pair->diff.period_ratio_delta;
>>> + switch (comparison_method) {
>>> + case COMPUTE_DELTA:
>>> + delta = pair->diff.period_ratio_delta;
>>> + break;
>>> + default:
>>> + BUG_ON(1);
>>> + }
>>>   else
>>> - percent = compute_delta(he, pair);
>>> + switch (comparison_method) {
>>> + case COMPUTE_DELTA:
>>> + delta = compute_delta(he, pair);
>>> + break;
>>> + default:
>>> + BUG_ON(1);
>>> + }
>>>
>>> - if (!he->dummy && fabs(percent) >= 0.01) {
>>> - scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
>>> - return color_snprintf(hpp->buf, hpp->size,
>>> - percent > 0 ? PERF_COLOR_GREEN : 
>>> PERF_COLOR_RED,
>>> - pfmt, percent);
>>> + if (!he->dummy) {
>>
>> isn't this check superfluous because of the above (!pair) check?
>
> From builtin-diff.c:get_pair_data(), we see that `pair' is one of the
> pairs in he->pairs. he->dummy is set in
> util/hist.c:hists__add_dummy_entry() which is called only when he
> doesn't have pairs (util/hist.c:942).

Sorry about the major thinko: hists__add_dummy_entry() returns a new
`he' with he->dummy set; it has nothing to do with pair->pairs of the
`pair' that it is passed.

I think I understand what's going on: I'll submit a new iteration soon.
--
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 v3 2/4] perf diff: generalize hpp__color_delta for -c

[Ramkumar Ramachandra]

Generalize the function so that we can accommodate all three comparison
methods: delta, ratio, and wdiff.

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index fe6e200..20284c3 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -769,31 +769,44 @@ static int hpp__entry_baseline(struct hist_entry *he, 
char *buf, size_t size)
return ret;
 }
 
-static int hpp__color_delta(struct perf_hpp_fmt *fmt,
-   struct perf_hpp *hpp, struct hist_entry *he)
+static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he,
+   int comparison_method)
 {
struct diff_hpp_fmt *dfmt =
container_of(fmt, struct diff_hpp_fmt, fmt);
struct hist_entry *pair = get_pair_fmt(he, dfmt);
-   double percent;
+   double diff;
char pfmt[20] = " ";
 
if (!pair)
goto dummy_print;
-   if (pair->diff.computed)
-   percent = pair->diff.period_ratio_delta;
-   else
-   percent = compute_delta(he, pair);
 
-   if (fabs(percent) >= 0.01) {
+   switch(comparison_method){
+   case COMPUTE_DELTA:
+   if (pair->diff.computed)
+   diff = pair->diff.period_ratio_delta;
+   else
+   diff = compute_delta(he, pair);
+
+   if (fabs(diff) < 0.01)
+   goto dummy_print;
scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
return color_snprintf(hpp->buf, hpp->size,
-   percent > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
-   pfmt, percent);
-   } else
+   diff > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
+   pfmt, diff);
+   default:
+   BUG_ON(1);
+   }
 dummy_print:
-   return scnprintf(hpp->buf, hpp->size, "%*s",
-   dfmt->header_width, pfmt);
+   return scnprintf(hpp->buf, hpp->size, "%*s",
+   dfmt->header_width, pfmt);
+}
+
+static int hpp__color_delta(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_DELTA);
 }
 
 static void
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v3 4/4] perf diff: color the Weighted Diff column

[Ramkumar Ramachandra]

In

  $ perf diff -c wdiff:M,N

color the numbers in the Weighted Diff column either green or red,
depending on whether the number is positive or negative.

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 26f6517..9422314 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -777,6 +777,7 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
container_of(fmt, struct diff_hpp_fmt, fmt);
struct hist_entry *pair = get_pair_fmt(he, dfmt);
double diff;
+   s64 wdiff;
char pfmt[20] = " ";
 
if (!pair)
@@ -806,6 +807,18 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
scnprintf(pfmt, 20, "%%%d.6f", dfmt->header_width);
return percent_color_snprintf(hpp->buf, hpp->size,
pfmt, diff);
+   case COMPUTE_WEIGHTED_DIFF:
+   if (he->dummy)
+   goto dummy_print;
+   if (pair->diff.computed)
+   wdiff = pair->diff.wdiff;
+   else
+   wdiff = compute_wdiff(he, pair);
+
+   scnprintf(pfmt, 20, "%%14ld", dfmt->header_width);
+   return color_snprintf(hpp->buf, hpp->size,
+   wdiff > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
+   pfmt, wdiff);
default:
BUG_ON(1);
}
@@ -826,6 +839,12 @@ static int hpp__color_ratio(struct perf_hpp_fmt *fmt,
return __hpp__color_compare(fmt, hpp, he, COMPUTE_RATIO);
 }
 
+static int hpp__color_wdiff(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_WEIGHTED_DIFF);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -1007,6 +1026,9 @@ static void data__hpp_register(struct data__file *d, int 
idx)
case PERF_HPP_DIFF__RATIO:
fmt->color = hpp__color_ratio;
break;
+   case PERF_HPP_DIFF__WEIGHTED_DIFF:
+   fmt->color = hpp__color_wdiff;
+   break;
default:
break;
}
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v3 1/4] perf diff: color the Delta column

[Ramkumar Ramachandra]

Color the numbers in the Delta column either green or red depending on
whether the number is positive or negative.

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 3b67ea2..fe6e200 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -769,6 +769,33 @@ static int hpp__entry_baseline(struct hist_entry *he, char 
*buf, size_t size)
return ret;
 }
 
+static int hpp__color_delta(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   struct diff_hpp_fmt *dfmt =
+   container_of(fmt, struct diff_hpp_fmt, fmt);
+   struct hist_entry *pair = get_pair_fmt(he, dfmt);
+   double percent;
+   char pfmt[20] = " ";
+
+   if (!pair)
+   goto dummy_print;
+   if (pair->diff.computed)
+   percent = pair->diff.period_ratio_delta;
+   else
+   percent = compute_delta(he, pair);
+
+   if (fabs(percent) >= 0.01) {
+   scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
+   return color_snprintf(hpp->buf, hpp->size,
+   percent > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
+   pfmt, percent);
+   } else
+dummy_print:
+   return scnprintf(hpp->buf, hpp->size, "%*s",
+   dfmt->header_width, pfmt);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -940,8 +967,16 @@ static void data__hpp_register(struct data__file *d, int 
idx)
fmt->entry  = hpp__entry_global;
 
/* TODO more colors */
-   if (idx == PERF_HPP_DIFF__BASELINE)
+   switch (idx) {
+   case PERF_HPP_DIFF__BASELINE:
fmt->color = hpp__color_baseline;
+   break;
+   case PERF_HPP_DIFF__DELTA:
+   fmt->color = hpp__color_delta;
+   break;
+   default:
+   break;
+   }
 
init_header(d, dfmt);
perf_hpp__column_register(fmt);
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v3 3/4] perf diff: color the Ratio column

[Ramkumar Ramachandra]

In

  $ perf diff -c ratio

color the Ratio column using percent_color_snprintf().

Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 20284c3..26f6517 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -795,6 +795,17 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
return color_snprintf(hpp->buf, hpp->size,
diff > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
pfmt, diff);
+   case COMPUTE_RATIO:
+   if (he->dummy)
+   goto dummy_print;
+   if (pair->diff.computed)
+   diff = pair->diff.period_ratio;
+   else
+   diff = compute_ratio(he, pair);
+
+   scnprintf(pfmt, 20, "%%%d.6f", dfmt->header_width);
+   return percent_color_snprintf(hpp->buf, hpp->size,
+   pfmt, diff);
default:
BUG_ON(1);
}
@@ -809,6 +820,12 @@ static int hpp__color_delta(struct perf_hpp_fmt *fmt,
return __hpp__color_compare(fmt, hpp, he, COMPUTE_DELTA);
 }
 
+static int hpp__color_ratio(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_RATIO);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -987,6 +1004,9 @@ static void data__hpp_register(struct data__file *d, int 
idx)
case PERF_HPP_DIFF__DELTA:
fmt->color = hpp__color_delta;
break;
+   case PERF_HPP_DIFF__RATIO:
+   fmt->color = hpp__color_ratio;
+   break;
default:
break;
}
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v3 0/4] More color in 'perf diff'

[Ramkumar Ramachandra]

Hi,

This iteration fixes several small problems in the previous iteration
pointed out by Jiri Olsa. Most significantly, the first patch has been
dropped, and there's just one switch-case statement for the entire
logic.

Thanks.

Ramkumar Ramachandra (4):
  perf diff: color the Delta column
  perf diff: generalize hpp__color_delta for -c
  perf diff: color the Ratio column
  perf diff: color the Weighted Diff column

 tools/perf/builtin-diff.c | 92 ++-
 1 file changed, 91 insertions(+), 1 deletion(-)

-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 1/4] perf diff: color the Delta column

[Ramkumar Ramachandra]

Jiri Olsa wrote:
> these colors are not consistent with colors in baseline,
> moreover all negative values are shown as red
>
> - please check get_percent_color function (used for baseline),
>   it checks the percentage against following values:
>
>   #define MIN_GREEN   0.5
>   #define MIN_RED 5.0

That was intentional. If you want colors that are consistent with the
baseline, what do we do about [4/4], where wdiff numbers can be huge?
(currently I use [green, red] for [positive, negative] there too)
--
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/4] perf diff: generalize hpp__color_delta for -c

[Ramkumar Ramachandra]

Jiri Olsa wrote:
> This patch basicaly factor the code you added in previous one.
>
> Could we use the function below from the beggining?

Yeah, I suppose I could squash this into [2/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 v4 1/3] perf diff: color the Delta column

[Ramkumar Ramachandra]

Color the numbers in the Delta column using percent_color_snprintf().
Generalize the function so that we can accommodate all three comparison
methods in the future: delta, ratio, and wdiff.

Cc: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 49 ++-
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 3b67ea2..c970aae 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -769,6 +769,45 @@ static int hpp__entry_baseline(struct hist_entry *he, char 
*buf, size_t size)
return ret;
 }
 
+static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he,
+   int comparison_method)
+{
+   struct diff_hpp_fmt *dfmt =
+   container_of(fmt, struct diff_hpp_fmt, fmt);
+   struct hist_entry *pair = get_pair_fmt(he, dfmt);
+   double diff;
+   char pfmt[20] = " ";
+
+   if (!pair)
+   goto dummy_print;
+
+   switch(comparison_method){
+   case COMPUTE_DELTA:
+   if (pair->diff.computed)
+   diff = pair->diff.period_ratio_delta;
+   else
+   diff = compute_delta(he, pair);
+
+   if (fabs(diff) < 0.01)
+   goto dummy_print;
+   scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
+   return percent_color_snprintf(hpp->buf, hpp->size,
+   pfmt, fabs(diff));
+   default:
+   BUG_ON(1);
+   }
+dummy_print:
+   return scnprintf(hpp->buf, hpp->size, "%*s",
+   dfmt->header_width, pfmt);
+}
+
+static int hpp__color_delta(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_DELTA);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -940,8 +979,16 @@ static void data__hpp_register(struct data__file *d, int 
idx)
fmt->entry  = hpp__entry_global;
 
/* TODO more colors */
-   if (idx == PERF_HPP_DIFF__BASELINE)
+   switch (idx) {
+   case PERF_HPP_DIFF__BASELINE:
fmt->color = hpp__color_baseline;
+   break;
+   case PERF_HPP_DIFF__DELTA:
+   fmt->color = hpp__color_delta;
+   break;
+   default:
+   break;
+   }
 
init_header(d, dfmt);
perf_hpp__column_register(fmt);
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v4 3/3] perf diff: color the Weighted Diff column

[Ramkumar Ramachandra]

In

  $ perf diff -c wdiff:M,N

color the numbers in the Weighted Diff column either green or red,
depending on whether the number is positive or negative.

Cc: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 25dac6c..d6ae643 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -777,6 +777,7 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
container_of(fmt, struct diff_hpp_fmt, fmt);
struct hist_entry *pair = get_pair_fmt(he, dfmt);
double diff;
+   s64 wdiff;
char pfmt[20] = " ";
 
if (!pair)
@@ -805,6 +806,18 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
scnprintf(pfmt, 20, "%%%d.6f", dfmt->header_width);
return percent_color_snprintf(hpp->buf, hpp->size,
pfmt, diff);
+   case COMPUTE_WEIGHTED_DIFF:
+   if (he->dummy)
+   goto dummy_print;
+   if (pair->diff.computed)
+   wdiff = pair->diff.wdiff;
+   else
+   wdiff = compute_wdiff(he, pair);
+
+   scnprintf(pfmt, 20, "%%14ld", dfmt->header_width);
+   return color_snprintf(hpp->buf, hpp->size,
+   wdiff > 0 ? PERF_COLOR_GREEN : PERF_COLOR_RED,
+   pfmt, wdiff);
default:
BUG_ON(1);
}
@@ -825,6 +838,12 @@ static int hpp__color_ratio(struct perf_hpp_fmt *fmt,
return __hpp__color_compare(fmt, hpp, he, COMPUTE_RATIO);
 }
 
+static int hpp__color_wdiff(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_WEIGHTED_DIFF);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -1006,6 +1025,9 @@ static void data__hpp_register(struct data__file *d, int 
idx)
case PERF_HPP_DIFF__RATIO:
fmt->color = hpp__color_ratio;
break;
+   case PERF_HPP_DIFF__WEIGHTED_DIFF:
+   fmt->color = hpp__color_wdiff;
+   break;
default:
break;
}
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v4 0/3] More color in 'perf diff'

[Ramkumar Ramachandra]

Hi,

Two minor changes in this iteration:

- The numbers in [1/3] are colored using percent_color_snprintf()
  instead of using (green, red) for (positive, negative).

- Two of the patches in the previous iteration were squashed together
  to make [2/3] in this iteration.

Thanks again to Jiri Olsa.

Cc: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 

Ramkumar Ramachandra (3):
  perf diff: color the Delta column
  perf diff: color the Ratio column
  perf diff: color the Weighted Diff column

 tools/perf/builtin-diff.c | 91 ++-
 1 file changed, 90 insertions(+), 1 deletion(-)

-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 v4 2/3] perf diff: color the Ratio column

[Ramkumar Ramachandra]

In

  $ perf diff -c ratio

color the Ratio column using percent_color_snprintf().

Cc: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-diff.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index c970aae..25dac6c 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -794,6 +794,17 @@ static int __hpp__color_compare(struct perf_hpp_fmt *fmt,
scnprintf(pfmt, 20, "%%%+d.2f", dfmt->header_width - 1);
return percent_color_snprintf(hpp->buf, hpp->size,
pfmt, fabs(diff));
+   case COMPUTE_RATIO:
+   if (he->dummy)
+   goto dummy_print;
+   if (pair->diff.computed)
+   diff = pair->diff.period_ratio;
+   else
+   diff = compute_ratio(he, pair);
+
+   scnprintf(pfmt, 20, "%%%d.6f", dfmt->header_width);
+   return percent_color_snprintf(hpp->buf, hpp->size,
+   pfmt, diff);
default:
BUG_ON(1);
}
@@ -808,6 +819,12 @@ static int hpp__color_delta(struct perf_hpp_fmt *fmt,
return __hpp__color_compare(fmt, hpp, he, COMPUTE_DELTA);
 }
 
+static int hpp__color_ratio(struct perf_hpp_fmt *fmt,
+   struct perf_hpp *hpp, struct hist_entry *he)
+{
+   return __hpp__color_compare(fmt, hpp, he, COMPUTE_RATIO);
+}
+
 static void
 hpp__entry_unpair(struct hist_entry *he, int idx, char *buf, size_t size)
 {
@@ -986,6 +1003,9 @@ static void data__hpp_register(struct data__file *d, int 
idx)
case PERF_HPP_DIFF__DELTA:
fmt->color = hpp__color_delta;
break;
+   case PERF_HPP_DIFF__RATIO:
+   fmt->color = hpp__color_ratio;
+   break;
default:
break;
}
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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] arm: remove duplicate includes

[Ramkumar Ramachandra]

As spotted by scripts/checkincludes.pl.

Cc: Russell King 
Signed-off-by: Ramkumar Ramachandra 
---
 arch/arm/kvm/handle_exit.c| 2 --
 arch/arm/mach-lpc32xx/phy3250.c   | 1 -
 arch/arm/mach-omap1/board-voiceblue.c | 1 -
 arch/arm/mach-sa1100/hackkit.c| 1 -
 arch/arm/mach-vexpress/v2m.c  | 1 -
 5 files changed, 6 deletions(-)

diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
index df4c82d..0366438 100644
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -26,8 +26,6 @@
 
 #include "trace.h"
 
-#include "trace.h"
-
 typedef int (*exit_handle_fn)(struct kvm_vcpu *, struct kvm_run *);
 
 static int handle_svc_hyp(struct kvm_vcpu *vcpu, struct kvm_run *run)
diff --git a/arch/arm/mach-lpc32xx/phy3250.c b/arch/arm/mach-lpc32xx/phy3250.c
index e54f87e..917ef29 100644
--- a/arch/arm/mach-lpc32xx/phy3250.c
+++ b/arch/arm/mach-lpc32xx/phy3250.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-omap1/board-voiceblue.c 
b/arch/arm/mach-omap1/board-voiceblue.c
index 4677a9c..4b382a0 100644
--- a/arch/arm/mach-omap1/board-voiceblue.c
+++ b/arch/arm/mach-omap1/board-voiceblue.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
diff --git a/arch/arm/mach-sa1100/hackkit.c b/arch/arm/mach-sa1100/hackkit.c
index 643d5f2..0016d25 100644
--- a/arch/arm/mach-sa1100/hackkit.c
+++ b/arch/arm/mach-sa1100/hackkit.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
index 95a469e..9f0eea6 100644
--- a/arch/arm/mach-vexpress/v2m.c
+++ b/arch/arm/mach-vexpress/v2m.c
@@ -6,7 +6,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
1.8.4.1.559.gdb9bdfb

--
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/3] MAINTAINERS: fix broken link to www.linux-kvm.org

[Ramkumar Ramachandra]

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Ramkumar Ramachandra 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3438384..1dd73f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4835,7 +4835,7 @@ KERNEL VIRTUAL MACHINE (KVM)
 M: Gleb Natapov 
 M: Paolo Bonzini 
 L: k...@vger.kernel.org
-W: http://linux-kvm.org
+W: http://www.linux-kvm.org
 S: Supported
 F: Documentation/*/kvm*.txt
 F: Documentation/virtual/kvm/
-- 
1.8.5.rc0

--
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/3] Documentation/kvm: patches should be against linux.git

[Ramkumar Ramachandra]

The document hasn't been updated since cf3e3d3 (KVM: Document KVM
specific review items, 2010-06-24); kvm does not have a separate
repository anymore.

Cc: Avi Kivity 
Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Ramkumar Ramachandra 
---
 Documentation/virtual/kvm/review-checklist.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/review-checklist.txt 
b/Documentation/virtual/kvm/review-checklist.txt
index a850986..8385c4d 100644
--- a/Documentation/virtual/kvm/review-checklist.txt
+++ b/Documentation/virtual/kvm/review-checklist.txt
@@ -4,7 +4,7 @@ Review checklist for kvm patches
 1.  The patch must follow Documentation/CodingStyle and
 Documentation/SubmittingPatches.
 
-2.  Patches should be against kvm.git master branch.
+2.  Patches should be against linux.git master branch.
 
 3.  If the patch introduces or modifies a new userspace API:
 - the API must be documented in Documentation/virtual/kvm/api.txt
-- 
1.8.5.rc0

--
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 3/3] Documentation/kvm: add a 00-INDEX file

[Ramkumar Ramachandra]

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Signed-off-by: Ramkumar Ramachandra 
---
 Documentation/virtual/kvm/00-INDEX | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/virtual/kvm/00-INDEX

diff --git a/Documentation/virtual/kvm/00-INDEX 
b/Documentation/virtual/kvm/00-INDEX
new file mode 100644
index 000..1d339cd
--- /dev/null
+++ b/Documentation/virtual/kvm/00-INDEX
@@ -0,0 +1,24 @@
+00-INDEX
+   - this file.
+api.txt
+   - the definitive KVM API documentation.
+cpuid.txt
+   - notes on KVM cpuid functions.
+devices/
+   - directory with info on device bindings for KVM_CAP_DEVICE_CTRL.
+hypercalls.txt
+   - info on the KVM hypercalls.
+locking.txt
+   - notes on KVM locks.
+mmu.txt
+   - the x86 kvm shadow mmu.
+msr.txt
+   - list of custom MSRs in KVM.
+nested-vmx.txt
+   - notes on a feature enabling nested VMX guests.
+ppc-pv.txt
+   - the paravirtualization interface on PowerPC.
+review-checklist.txt
+   - review checklist for KVM patches.
+timekeeping.txt
+   - info on timekeeping virtualization for x86-based architectures.
-- 
1.8.5.rc0

--
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 0/3] Small patches around kvm doc

[Ramkumar Ramachandra]

Hi,

I was going through the kvm documentation when I noticed the following
minor nits.

Thanks.

Ramkumar Ramachandra (3):
  MAINTAINERS: fix broken link to www.linux-kvm.org
  Documentation/kvm: patches should be against linux.git
  Documentation/kvm: add a 00-INDEX file

 Documentation/virtual/kvm/00-INDEX | 24 
 Documentation/virtual/kvm/review-checklist.txt |  2 +-
 MAINTAINERS|  2 +-
 3 files changed, 26 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/virtual/kvm/00-INDEX

-- 
1.8.5.rc0

--
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 v2] MAINTAINERS: add tree for kvm.git

[Ramkumar Ramachandra]

Cc: Gleb Natapov 
Cc: Paolo Bonzini 
Cc: KVM List 
Signed-off-by: Ramkumar Ramachandra 
---
 This is a replacement for [PATCH 2/3] Documentation/kvm: patches
 should be against linux.git

 Thanks to Paolo for pointing to the right tree.

 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1dd73f7..36b05119 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4836,6 +4836,7 @@ M:Gleb Natapov 
 M: Paolo Bonzini 
 L: k...@vger.kernel.org
 W: http://www.linux-kvm.org
+T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
 S: Supported
 F: Documentation/*/kvm*.txt
 F: Documentation/virtual/kvm/
-- 
1.8.5.rc0

--
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 0/5] zsh support for perf completion

[Ramkumar Ramachandra]

Hi,

I'm pleased to announce zsh support for the perf completion script,
added this lazy Sunday afternoon. I'm not very good at shell
scripting, so these patches can definitely use more eyes. Frankly, I'm
mildly surprised that this hack even works: please test carefully and
report bugs.

[1/5] to [3/5] factors things out and prepares the stage for [4/5],
which is the focus of the series. [5/5] is just a pure rename.

Thanks.

Ramkumar Ramachandra (5):
  perf completion: introduce a layer of indirection
  perf completion: factor out compgen stuff
  perf completion: factor out call to __ltrim_colon_completions
  perf completion: introduce zsh support
  perf completion: rename file to reflect zsh support

 tools/perf/{bash_completion => perf-completion.sh} | 100 ++---
 1 file changed, 88 insertions(+), 12 deletions(-)
 rename tools/perf/{bash_completion => perf-completion.sh} (65%)

-- 
1.8.5.rc0.6.gfd75b41

--
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 3/5] perf completion: factor out call to __ltrim_colon_completions

[Ramkumar Ramachandra]

In our sole callsite, __ltrim_colon_completions is called after
__perfcomp, to modify the COMPREPLY set by the invocation. This is
problematic, because in the zsh equivalent (using compset/ compadd),
we'll have to generate completions in one-shot. So factor out this
entire callsite into a special override'able __perfcomp_colon function;
we will override it when introducing zsh support.

Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/bash_completion | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tools/perf/bash_completion b/tools/perf/bash_completion
index 82431268..573599b 100644
--- a/tools/perf/bash_completion
+++ b/tools/perf/bash_completion
@@ -94,6 +94,12 @@ __perfcomp ()
COMPREPLY=( $( compgen -W "$1" -- "$2" ) )
 }
 
+__perfcomp_colon ()
+{
+   __perfcomp "$1" "$2"
+   __ltrim_colon_completions $cur
+}
+
 __perf_main ()
 {
local cmd
@@ -114,8 +120,7 @@ __perf_main ()
# List possible events for -e option
elif [[ $prev == "-e" && "${words[1]}" == @(record|stat|top) ]]; then
evts=$($cmd list --raw-dump)
-   __perfcomp "$evts" "$cur"
-   __ltrim_colon_completions $cur
+   __perfcomp_colon "$evts" "$cur"
# List long option names
elif [[ $cur == --* ]];  then
subcmd=${words[1]}
-- 
1.8.5.rc0.6.gfd75b41

--
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/5] perf completion: factor out compgen stuff

[Ramkumar Ramachandra]

compgen is a bash-builtin; factor out the invocations into a separate
function to give us a chance to override it with a zsh equivalent in
future patches.

Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/bash_completion | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/perf/bash_completion b/tools/perf/bash_completion
index 3efdc84..82431268 100644
--- a/tools/perf/bash_completion
+++ b/tools/perf/bash_completion
@@ -89,6 +89,11 @@ __ltrim_colon_completions()
fi
 }
 
+__perfcomp ()
+{
+   COMPREPLY=( $( compgen -W "$1" -- "$2" ) )
+}
+
 __perf_main ()
 {
local cmd
@@ -99,23 +104,23 @@ __perf_main ()
# List perf subcommands or long options
if [ $cword -eq 1 ]; then
if [[ $cur == --* ]]; then
-   COMPREPLY=( $( compgen -W '--help --version \
+   __perfcomp '--help --version \
--exec-path --html-path --paginate --no-pager \
-   --perf-dir --work-tree --debugfs-dir' -- "$cur" ) )
+   --perf-dir --work-tree --debugfs-dir' -- "$cur"
else
cmds=$($cmd --list-cmds)
-   COMPREPLY=( $( compgen -W '$cmds' -- "$cur" ) )
+   __perfcomp "$cmds" "$cur"
fi
# List possible events for -e option
elif [[ $prev == "-e" && "${words[1]}" == @(record|stat|top) ]]; then
evts=$($cmd list --raw-dump)
-   COMPREPLY=( $( compgen -W '$evts' -- "$cur" ) )
+   __perfcomp "$evts" "$cur"
__ltrim_colon_completions $cur
# List long option names
elif [[ $cur == --* ]];  then
subcmd=${words[1]}
opts=$($cmd $subcmd --list-opts)
-   COMPREPLY=( $( compgen -W '$opts' -- "$cur" ) )
+   __perfcomp "$opts" "$cur"
fi
 }
 
-- 
1.8.5.rc0.6.gfd75b41

--
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/5] perf completion: introduce a layer of indirection

[Ramkumar Ramachandra]

Define the variables cur, words, cword, and prev outside the main
completion function so that we have a chance to override it when we
introduce zsh support.

Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/bash_completion | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/tools/perf/bash_completion b/tools/perf/bash_completion
index 62e157db..3efdc84 100644
--- a/tools/perf/bash_completion
+++ b/tools/perf/bash_completion
@@ -89,15 +89,12 @@ __ltrim_colon_completions()
fi
 }
 
-type perf &>/dev/null &&
-_perf()
+__perf_main ()
 {
-   local cur words cword prev cmd
-
-   COMPREPLY=()
-   _get_comp_words_by_ref -n =: cur words cword prev
+   local cmd
 
cmd=${words[0]}
+   COMPREPLY=()
 
# List perf subcommands or long options
if [ $cword -eq 1 ]; then
@@ -120,6 +117,14 @@ _perf()
opts=$($cmd $subcmd --list-opts)
COMPREPLY=( $( compgen -W '$opts' -- "$cur" ) )
fi
+}
+
+type perf &>/dev/null &&
+_perf()
+{
+   local cur words cword prev
+   _get_comp_words_by_ref -n =: cur words cword prev
+   __perf_main
 } &&
 
 complete -o bashdefault -o default -o nospace -F _perf perf 2>/dev/null \
-- 
1.8.5.rc0.6.gfd75b41

--
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/5] perf completion: introduce zsh support

[Ramkumar Ramachandra]

__perfcomp(), __perfcomp_colon(), and _perf() have to be
overridden. Inspired by the way the git.git completion system is
structured.

Cc: Namhyung Kim 
Cc: Frederic Weisbecker 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/bash_completion | 63 +-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/tools/perf/bash_completion b/tools/perf/bash_completion
index 573599b..4949488 100644
--- a/tools/perf/bash_completion
+++ b/tools/perf/bash_completion
@@ -1,4 +1,4 @@
-# perf completion
+# perf bash and zsh completion
 
 # Taken from git.git's completion script.
 __my_reassemble_comp_words_by_ref()
@@ -129,6 +129,67 @@ __perf_main ()
fi
 }
 
+if [[ -n ${ZSH_VERSION-} ]]; then
+   autoload -U +X compinit && compinit
+
+   __perfcomp ()
+   {
+   emulate -L zsh
+
+   local c IFS=$' \t\n'
+   local -a array
+
+   for c in ${=1}; do
+   case $c in
+   --*=*|*.) ;;
+   *) c="$c " ;;
+   esac
+   array[${#array[@]}+1]="$c"
+   done
+
+   compset -P '*[=:]'
+   compadd -Q -S '' -a -- array && _ret=0
+   }
+
+   __perfcomp_colon ()
+   {
+   emulate -L zsh
+
+   local cur_="${2-$cur}"
+   local c IFS=$' \t\n'
+   local -a array
+
+   if [[ "$cur_" == *:* ]]; then
+   local colon_word=${cur_%"${cur_##*:}"}
+   fi
+
+   for c in ${=1}; do
+   case $c in
+   --*=*|*.) ;;
+   *) c="$c " ;;
+   esac
+   array[$#array+1]=${c#"$colon_word"}
+   done
+
+   compset -P '*[=:]'
+   compadd -Q -S '' -a -- array && _ret=0
+   }
+
+   _perf ()
+   {
+   local _ret=1 cur cword prev
+   cur=${words[CURRENT]}
+   prev=${words[CURRENT-1]}
+   let cword=CURRENT-1
+   emulate ksh -c __perf_main
+   let _ret && _default && _ret=0
+   return _ret
+   }
+
+   compdef _perf perf
+   return
+fi
+
 type perf &>/dev/null &&
 _perf()
 {
-- 
1.8.5.rc0.6.gfd75b41

--
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 5/5] perf completion: rename file to reflect zsh support

[Ramkumar Ramachandra]

Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/{bash_completion => perf-completion.sh} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename tools/perf/{bash_completion => perf-completion.sh} (100%)

diff --git a/tools/perf/bash_completion b/tools/perf/perf-completion.sh
similarity index 100%
rename from tools/perf/bash_completion
rename to tools/perf/perf-completion.sh
-- 
1.8.5.rc0.6.gfd75b41

--
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 2/3] perf diff: color the Ratio column

[Ramkumar Ramachandra]

Arnaldo Carvalho de Melo wrote:
> static inline percent_color_snprintf(...)
> {
> return value_color_snprintf(...);
> }

The issue with this suggestion is that the prototype of
percent_color_snprintf() is:

  int percent_color_snprintf(char *bf, size_t size, const char *fmt, ...)

So, I can only pass value_color_snprintf() a va_list, making its prototype:

  int value_color_snprintf(char *bf, size_t size, const char *fmt, va_list args)

Is this worth the minor rename?

On a related note, does percent_color_snprintf() need to be a variadic
function? It only seems to process one percent value.
--
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 2/3] perf diff: color the Ratio column

[Ramkumar Ramachandra]

Arnaldo Carvalho de Melo wrote:
>> The issue with this suggestion is that the prototype of
>> percent_color_snprintf() is:
>>
>>   int percent_color_snprintf(char *bf, size_t size, const char *fmt, ...)
>>
>> So, I can only pass value_color_snprintf() a va_list, making its prototype:
>>
>>   int value_color_snprintf(char *bf, size_t size, const char *fmt, va_list 
>> args)
>>
>> Is this worth the minor rename?
>
> That is ok, I'd say. Or if that would be a problem one could consider
> using a macro, perhaps.

If value_color_snprintf has the prototype mentioned above, I'd have to
build a va_list at each callsite; how is that convenient? Considering
the macro, can we just do

  #define percent_color_snprintf value_color_snprintf

in color.h?

>> On a related note, does percent_color_snprintf() need to be a variadic
>> function? It only seems to process one percent value.
>
> I think that there are places where it is passed as a pointer that
> expects it to have that prototype, this is from memory, so please check.

I meant that the function body itself seems to be wrong:

  va_start(args, fmt);
  percent = va_arg(args, double);
  va_end(args);
  color = get_percent_color(percent);
  return color_snprintf(bf, size, color, fmt, percent);

Unless I've misunderstood something horribly, doesn't `percent' just
get assigned to the last argument in the `args' va_list?
--
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] perf list: fix --raw-dump

[Ramkumar Ramachandra]

While adding usage information, 44d742e (perf list: Add usage,
2013-10-30) broke

  $ perf list --raw-dump

by asking parse_options() to stop at
non-option (PARSE_OPT_STOP_AT_NON_OPTION), hence parsing the option
--raw-dump and barfing. Ask it to keep unknown options
unparsed (PARSE_OPT_KEEP_UNKNOWN) so that we have a chance to handle it
later. The trade-off that this patch makes is that

  $ perf list --foo

will not error out like it used to.

Fixes: 44d742e01e6d (perf list: Add usage)
Cc: David Ahern 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 I spotted this while trying to complete

   $ perf record -e 

 tools/perf/builtin-list.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..8b076f3 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -28,7 +28,7 @@ int cmd_list(int argc, const char **argv, const char *prefix 
__maybe_unused)
};
 
argc = parse_options(argc, argv, list_options, list_usage,
-PARSE_OPT_STOP_AT_NON_OPTION);
+   PARSE_OPT_KEEP_UNKNOWN);
 
setup_pager();
 
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 completion: complete 'perf kvm'

[Ramkumar Ramachandra]

Currently, there is no way to enumerate the subcommands under 'perf
kvm', so hardcode them.

Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/perf-completion.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/perf/perf-completion.sh b/tools/perf/perf-completion.sh
index 4949488..496e2ab 100644
--- a/tools/perf/perf-completion.sh
+++ b/tools/perf/perf-completion.sh
@@ -121,6 +121,10 @@ __perf_main ()
elif [[ $prev == "-e" && "${words[1]}" == @(record|stat|top) ]]; then
evts=$($cmd list --raw-dump)
__perfcomp_colon "$evts" "$cur"
+   # List subcommands for 'perf kvm'
+   elif [[ $prev == "kvm" ]]; then
+   subcmds="top record report diff buildid-list stat"
+   __perfcomp_colon "$subcmds" "$cur"
# List long option names
elif [[ $cur == --* ]];  then
subcmd=${words[1]}
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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 0/2] Completion for 'perf kvm'

[Ramkumar Ramachandra]

Hi,

These are based on tip/master.

Thanks.

Ramkumar Ramachandra (2):
  perf completion: complete 'perf kvm'
  perf tools: ignore files generated by 'perf kvm'

 tools/perf/.gitignore | 2 ++
 tools/perf/perf-completion.sh | 4 
 2 files changed, 6 insertions(+)

-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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: ignore files generated by 'perf kvm'

[Ramkumar Ramachandra]

Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/.gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
index 782d86e..28264a9 100644
--- a/tools/perf/.gitignore
+++ b/tools/perf/.gitignore
@@ -13,6 +13,8 @@ perf*.html
 common-cmds.h
 perf.data
 perf.data.old
+perf.data.guest
+perf.data.guest.old
 output.svg
 perf-archive
 tags
-- 
1.8.5.rc0.5.g70ebc73.dirty

--
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] perf list: fix --raw-dump

[Ramkumar Ramachandra]

David Ahern wrote:
> Why not make raw_dump a proper argument?

Sure, that'd work too. I was thinking of a minimal way to fix the
problem myself.

> diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
> index 011195e38f21..b553d0c4ca82 100644
> --- a/tools/perf/builtin-list.c
> +++ b/tools/perf/builtin-list.c
> @@ -36,6 +38,10 @@ int cmd_list(int argc, const char
>  print_events(NULL, false);
>  return 0;
>}
> +  if (raw_dump) {
> +print_events(NULL, true);
> +return 0;
> +  }

This won't work because you've put it right below the `if (argc ==
0)`, which executes print_events(). You could move it up and get it to
work.
From 7198a494cfef43395e8683ac3a0576277b8d1d80 Mon Sep 17 00:00:00 2001
From: David Ahern 
Date: Wed, 11 Dec 2013 14:00:20 -0700
Subject: [PATCH] perf list: Fix raw-dump arg

Ramkumar reported that perf list --raw-dump was broken by 44d742e.
Fix by making raw-dump a proper argument.

Signed-off-by: David Ahern 
Cc: Ingo Molnar 
Cc: Arnaldo Carvalho de Melo 
Cc: Ramkumar Ramachandra 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-list.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 011195e..2629c24 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -19,7 +19,9 @@
 int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
 {
 	int i;
+	bool raw_dump = false;
 	const struct option list_options[] = {
+		OPT_BOOLEAN(0, "raw-dump", _dump, "raw dump for completion"),
 		OPT_END()
 	};
 	const char * const list_usage[] = {
@@ -32,6 +34,10 @@ int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
 
 	setup_pager();
 
+	if (raw_dump) {
+		print_events(NULL, true);
+		return 0;
+	}
 	if (argc == 0) {
 		print_events(NULL, false);
 		return 0;
@@ -53,8 +59,6 @@ int cmd_list(int argc, const char **argv, const char *prefix __maybe_unused)
 			print_hwcache_events(NULL, false);
 		else if (strcmp(argv[i], "pmu") == 0)
 			print_pmu_events(NULL, false);
-		else if (strcmp(argv[i], "--raw-dump") == 0)
-			print_events(NULL, true);
 		else {
 			char *sep = strchr(argv[i], ':'), *s;
 			int sep_idx;
-- 
1.8.5.1.113.g8cb5bef.dirty

[PATCH v2] perf tools: ignore files generated by 'perf kvm'

[Ramkumar Ramachandra]

Signed-off-by: Ramkumar Ramachandra 
---
 Include .kvm[.old], .host[.old] files, as suggested by Arnaldo.

 tools/perf/.gitignore | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tools/perf/.gitignore b/tools/perf/.gitignore
index 782d86e..9fea0d9 100644
--- a/tools/perf/.gitignore
+++ b/tools/perf/.gitignore
@@ -13,6 +13,12 @@ perf*.html
 common-cmds.h
 perf.data
 perf.data.old
+perf.data.guest
+perf.data.guest.old
+perf.data.kvm
+perf.data.kvm.old
+perf.data.host
+perf.data.host.old
 output.svg
 perf-archive
 tags
-- 
1.8.5.1.113.g8cb5bef.dirty

--
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/2] perf completion: complete 'perf kvm'

[Ramkumar Ramachandra]

David Ahern wrote:
> I don't like the command list being embedded in the completion script. It
> will get outdated quickly.

I could introduce a

  $ perf kvm --list-cmds

but that would mean a

  printf("record report stat ..")

in builtin-kvm.c, because the commands aren't in any sort of 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/

[PATCH] perf kvm: introduce --list-cmds for use by scripts

[Ramkumar Ramachandra]

Introduce

  $ perf kvm --list-cmds

to dump a raw list of commands for use by the completion script. While
at it, refactor kvm_usage so that there's only one copy of the command
listing.

Cc: David Ahern 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 David Ahern wrote:
 > That would work -- perhaps a #define or string near
 >
 >const char * const kvm_usage[] = {
 > "perf kvm [] {top|record|report|diff|buildid-list|stat}",
 > NULL
 > };
 >
 > Building kvm_usage from the string would better - only 1 place listing the
 > commands.

 Something like this, perhaps? It's not too pretty though: do you have
 suggestions to prettify it?

 tools/perf/builtin-kvm.c  | 25 +
 tools/perf/perf-completion.sh |  2 +-
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index c6fa3cb..ce44a9b 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -1672,6 +1672,7 @@ __cmd_buildid_list(const char *file_name, int argc, const 
char **argv)
 int cmd_kvm(int argc, const char **argv, const char *prefix __maybe_unused)
 {
const char *file_name = NULL;
+   bool list_cmds = false;
const struct option kvm_options[] = {
OPT_STRING('i', "input", _name, "file",
   "Input file name"),
@@ -1692,20 +1693,36 @@ int cmd_kvm(int argc, const char **argv, const char 
*prefix __maybe_unused)
   "file", "file saving guest os /proc/modules"),
OPT_INCR('v', "verbose", ,
"be more verbose (show counter open errors, etc)"),
+   OPT_BOOLEAN(0, "list-cmds", _cmds,
+   "list commands raw for use by scripts"),
OPT_END()
};
 
+   const char *const commands[] = { "top", "record", "report", "diff",
+"buildid-list", "stat", NULL };
+   char kvm_usage_str[80];
+   const char *kvm_usage[] = { NULL, NULL };
 
-   const char * const kvm_usage[] = {
-   "perf kvm [] 
{top|record|report|diff|buildid-list|stat}",
-   NULL
-   };
+   sprintf(kvm_usage_str, "%s", "perf kvm [] {");
+   for (int i = 0; commands[i]; i++) {
+   if (i)
+   strcat(kvm_usage_str, "|");
+   strcat(kvm_usage_str, commands[i]);
+   }
+   strcat(kvm_usage_str, "}");
+
+   kvm_usage[0] = kvm_usage_str;
 
perf_host  = 0;
perf_guest = 1;
 
argc = parse_options(argc, argv, kvm_options, kvm_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
+   if (list_cmds) {
+   for (int i = 0; commands[i]; i++)
+   printf("%s ", commands[i]);
+   return 0;
+   }
if (!argc)
usage_with_options(kvm_usage, kvm_options);
 
diff --git a/tools/perf/perf-completion.sh b/tools/perf/perf-completion.sh
index 496e2ab..d8bfa43 100644
--- a/tools/perf/perf-completion.sh
+++ b/tools/perf/perf-completion.sh
@@ -123,7 +123,7 @@ __perf_main ()
__perfcomp_colon "$evts" "$cur"
# List subcommands for 'perf kvm'
elif [[ $prev == "kvm" ]]; then
-   subcmds="top record report diff buildid-list stat"
+   subcmds=$($cmd kvm --list-cmds)
__perfcomp_colon "$subcmds" "$cur"
# List long option names
elif [[ $cur == --* ]];  then
-- 
1.8.5.1.113.g8cb5bef.dirty

--
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: Beyond inotify recursive watches

[Ramkumar Ramachandra]

Jan Kara wrote:
>   Initially, you will have to flip the flag on every directory in the
> subtree. But the flag is persistently stored on disk so you have to do it
> once when the directory is created and then each time you notice the
> directory has changed and the flag has been cleared.

How is this any better than setting up inotify recursively on the
directory tree?  I'll have to readdir() each directory in the tree,
looking for more directories to set the flag on.

>   I think Al is asking how do we lock kernel dentry cache so that we can
> safely walk up the tree and update time stamps in presence of other
> modifications happening to the directory tree in parallel.

>   It's not as much timestamp updates themselves racing against each other
> but rather things like moving directories in the directory tree racing with
> us walking up the tree and updating time stamps - in Linux, directory
> locking happens in top-bottom manner (like when you do lookup of a path) so
> when you are climbing up, one has to be careful not to introduce races.

Oh.  So we need to carefully code very fine-grained locking (so that
the entire fs isn't unusable when this recursive update is happening).

>   One reason why we need things to be fs-internal is that we want to store
> everything permanently on disk so that e.g. if there's reboot between
> modification of a git tree and 'git add -u', you will still find what has
> changed since last time you've checked (without walking the whole tree).

Makes sense.  However, doesn't this mean that we have to patch every
filesystem separately for this feature, as opposed to just patching
VFS?

>   My concern is that if you have a directory tree where there are lots of
> entries in each directory, then you still have to check a lot of entries
> before you find what has changed because you have to scan all entries in
> each directory on the modified path. If there was a way to iterate only
> through entries in a directory which had the flag cleared, things could be
> considerably faster.

What are your thoughts on introducing a version of readdir() that only
lists dentries with this flag?

Can you get deeper into the implementation, and point me to the parts
of the code to look at?  Do you have any WIP patches that I can look
at?
--
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 3/4] drm/i915: prepare intel_lvds_get_edid() for multiple calls

[Ramkumar Ramachandra]

intel_lvds_get_edid() needs to be called when switching GPUs, but it
currently assumes that it will only be called once and that there's
always an LVDS connector present when it's called. Fix this assumptions.

Cc: Andreas Heider 
Cc: Seth Forshee 
Original-patch-by: Seth Forshee 
Signed-off-by: Ramkumar Ramachandra 
---
 drivers/gpu/drm/i915/intel_lvds.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 6c09617..8275551 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -927,10 +927,18 @@ static bool intel_lvds_get_edid(struct drm_device *dev)
struct edid *edid;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_connector *connector = dev_priv->int_lvds_connector;
-   struct intel_lvds_connector *lvds_connector = 
to_lvds_connector(connector);
+   struct intel_lvds_connector *lvds_connector;
struct drm_display_mode *scan; /* *modes, *bios_mode; */
struct drm_display_mode *fixed_mode = NULL;
 
+   if (!connector)
+   return false;
+   lvds_connector = to_lvds_connector(connector);
+
+   /* If we already have an EDID, no need to check again */
+   if (lvds_connector->base.edid)
+   return true;
+
/*
 * Attempt to get the fixed panel mode from DDC.  Assume that the
 * preferred mode is the right one.
-- 
1.8.5.2.229.g4448466

--
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/4] drm/i915: add support for vga_switcheroo reprobe

[Ramkumar Ramachandra]

Cc: Andreas Heider 
Cc: Seth Forshee 
Original-patch-by: Andreas Heider 
Signed-off-by: Ramkumar Ramachandra 
---
 drivers/gpu/drm/i915/i915_dma.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5c64842..336a835b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1265,6 +1265,12 @@ static void i915_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switcheroo_
}
 }
 
+static void i915_switcheroo_reprobe(struct pci_dev *pdev)
+{
+   struct drm_device *dev = pci_get_drvdata(pdev);
+   intel_fbdev_output_poll_changed(dev);
+}
+
 static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
@@ -1278,7 +1284,7 @@ static bool i915_switcheroo_can_switch(struct pci_dev 
*pdev)
 
 static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
.set_gpu_state = i915_switcheroo_set_state,
-   .reprobe = NULL,
+   .reprobe = i915_switcheroo_reprobe,
.can_switch = i915_switcheroo_can_switch,
 };
 
-- 
1.8.5.2.229.g4448466

--
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/4] drm/i915: check LVDS for EDID on GPU switches

[Ramkumar Ramachandra]

If the LVDS panel wasn't connected at boot then we won't have an EDID
for it. To fix this, call intel_lvds_get_edid() from the vga_switcheroo
reprobe callback.

Cc: Andreas Heider 
Cc: Seth Forshee 
Original-patch-by: Seth Forshee 
Signed-off-by: Ramkumar Ramachandra 
---
 drivers/gpu/drm/i915/i915_dma.c   | 1 +
 drivers/gpu/drm/i915/intel_drv.h  | 1 +
 drivers/gpu/drm/i915/intel_lvds.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 336a835b..5eb37a3 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1268,6 +1268,7 @@ static void i915_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switcheroo_
 static void i915_switcheroo_reprobe(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
+   intel_lvds_get_edid(dev);
intel_fbdev_output_poll_changed(dev);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 79f91f2..686954f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -769,6 +769,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
 
 
 /* intel_lvds.c */
+bool intel_lvds_get_edid(struct drm_device *dev);
 void intel_lvds_init(struct drm_device *dev);
 bool intel_is_dual_link_lvds(struct drm_device *dev);
 
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 8275551..f700355 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -922,7 +922,7 @@ static bool intel_lvds_supported(struct drm_device *dev)
return false;
 }
 
-static bool intel_lvds_get_edid(struct drm_device *dev)
+bool intel_lvds_get_edid(struct drm_device *dev)
 {
struct edid *edid;
struct drm_i915_private *dev_priv = dev->dev_private;
-- 
1.8.5.2.229.g4448466

--
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/4] drm/i915: factor out intel_lvds_get_edid()

[Ramkumar Ramachandra]

This code will be reused to support hybrid graphics on some Apple
machines that can't get a mode for the LVDS panel at boot, so move it
into a new function named intel_lvds_get_edid().

Cc: Andreas Heider 
Cc: Seth Forshee 
Original-patch-by: Seth Forshee 
Signed-off-by: Ramkumar Ramachandra 
---
 drivers/gpu/drm/i915/i915_drv.h   |   1 +
 drivers/gpu/drm/i915/intel_lvds.c | 104 ++
 2 files changed, 61 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90fcccb..2c055f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1496,6 +1496,7 @@ typedef struct drm_i915_private {
} wm;
 
struct i915_package_c8 pc8;
+   struct drm_connector *int_lvds_connector;
 
/* Old dri1 support infrastructure, beware the dragons ya fools entering
 * here! */
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index c3b4da7..6c09617 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -42,6 +42,7 @@
 /* Private structure for the integrated LVDS support */
 struct intel_lvds_connector {
struct intel_connector base;
+   u8 i2c_pin;
 
struct notifier_block lid_notifier;
 };
@@ -921,6 +922,60 @@ static bool intel_lvds_supported(struct drm_device *dev)
return false;
 }
 
+static bool intel_lvds_get_edid(struct drm_device *dev)
+{
+   struct edid *edid;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_connector *connector = dev_priv->int_lvds_connector;
+   struct intel_lvds_connector *lvds_connector = 
to_lvds_connector(connector);
+   struct drm_display_mode *scan; /* *modes, *bios_mode; */
+   struct drm_display_mode *fixed_mode = NULL;
+
+   /*
+* Attempt to get the fixed panel mode from DDC.  Assume that the
+* preferred mode is the right one.
+*/
+   edid = drm_get_edid(connector, intel_gmbus_get_adapter(dev_priv, 
lvds_connector->i2c_pin));
+   if (edid) {
+   if (drm_add_edid_modes(connector, edid)) {
+   drm_mode_connector_update_edid_property(connector,
+   edid);
+   } else {
+   kfree(edid);
+   edid = ERR_PTR(-EINVAL);
+   }
+   } else {
+   edid = ERR_PTR(-ENOENT);
+   }
+   lvds_connector->base.edid = edid;
+
+   if (IS_ERR_OR_NULL(edid)) {
+   /* Didn't get an EDID, so
+* Set wide sync ranges so we get all modes
+* handed to valid_mode for checking
+*/
+   connector->display_info.min_vfreq = 0;
+   connector->display_info.max_vfreq = 200;
+   connector->display_info.min_hfreq = 0;
+   connector->display_info.max_hfreq = 200;
+   }
+
+   list_for_each_entry(scan, >probed_modes, head) {
+   if (scan->type & DRM_MODE_TYPE_PREFERRED) {
+   DRM_DEBUG_KMS("using preferred mode from EDID: ");
+   drm_mode_debug_printmodeline(scan);
+
+   fixed_mode = drm_mode_duplicate(dev, scan);
+   if (fixed_mode) {
+   intel_find_lvds_downclock(dev, fixed_mode,
+ connector);
+   return true;
+   }
+   }
+   }
+   return false;
+}
+
 /**
  * intel_lvds_init - setup LVDS connectors on this device
  * @dev: drm device
@@ -937,9 +992,7 @@ void intel_lvds_init(struct drm_device *dev)
struct intel_connector *intel_connector;
struct drm_connector *connector;
struct drm_encoder *encoder;
-   struct drm_display_mode *scan; /* *modes, *bios_mode; */
struct drm_display_mode *fixed_mode = NULL;
-   struct edid *edid;
struct drm_crtc *crtc;
u32 lvds;
int pipe;
@@ -978,11 +1031,13 @@ void intel_lvds_init(struct drm_device *dev)
}
 
lvds_encoder->attached_connector = lvds_connector;
+   lvds_connector->i2c_pin = pin;
 
intel_encoder = _encoder->base;
encoder = _encoder->base;
intel_connector = _connector->base;
connector = _connector->base;
+   dev_priv->int_lvds_connector = connector;
drm_connector_init(dev, _connector->base, 
_lvds_connector_funcs,
   DRM_MODE_CONNECTOR_LVDS);
 
@@ -1036,48 +1091,8 @@ void intel_lvds_init(struct drm_device *dev)
 *if closed, act like it's not there for now
 */
 
-   /*
-* Attempt to get the fixed panel mode from DDC.  Assume that the
-* preferred mode is the right one.
- 

[PATCH 0/4] Get EDID late for VGA switcheroo

[Ramkumar Ramachandra]

Hi,

VGA switcheroo doesn't work on my 2013 MBP, and I'm trying to fix
it. From what I've gathered from previous patches, it seems that the
EDID is not computed at boottime, because LVDS isn't connected to the
i915 card (and is connected to the nouveau card instead). So, here's a
series to get switcheroo-reprobe to call get-edid. I think it's a step
in the right direction, although I think more stuff is required to fix
the issue.

Disclaimer: The series might be utter rubbish, because this is my
first attempt at any driver code.

Thanks.

Cc: Andreas Heider 
Cc: Seth Forshee 

Ramkumar Ramachandra (4):
  drm/i915: add support for vga_switcheroo reprobe
  drm/i915: factor out intel_lvds_get_edid()
  drm/i915: prepare intel_lvds_get_edid() for multiple calls
  drm/i915: check LVDS for EDID on GPU switches

 drivers/gpu/drm/i915/i915_dma.c   |   9 ++-
 drivers/gpu/drm/i915/i915_drv.h   |   1 +
 drivers/gpu/drm/i915/intel_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_lvds.c | 112 +++---
 4 files changed, 78 insertions(+), 45 deletions(-)

-- 
1.8.5.2.229.g4448466

--
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: [QUERY] Power consumption on a 2013 MBP

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> My system freezes if I remove modules like usbhci, ahci, ehci_hcd.

Correction: my input devices (keyboard, trackpad) depend on usbhci,
ehci_hcd, while libata and my hard disk drivers depend on ahci;
there's no way I can do without them. I'm trying to get VGA switcheroo
to work so I can switch to the onboard i915 graphics card in the hope
of saving power.
--
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/4] drm/i915: add support for vga_switcheroo reprobe

[Ramkumar Ramachandra]

Hi Chris,

Chris Wilson wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c 
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index 5c64842..336a835b 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
>> @@ -1265,6 +1265,12 @@ static void i915_switcheroo_set_state(struct pci_dev 
>> *pdev, enum vga_switcheroo_
>>   }
>>  }
>>
>> +static void i915_switcheroo_reprobe(struct pci_dev *pdev)
>> +{
>> + struct drm_device *dev = pci_get_drvdata(pdev);
>> + intel_fbdev_output_poll_changed(dev);
>> +}
>
> switcheroo should be sending a hotplug notification, which should
> trigger both this kernel listener and userspace.

If I understand correctly, switcheroo will send a hotplug notification
when LVDS is connected to the i915 device, and trigger this reprobe
function(), which in a later patch calls get-edid. Right?
--
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/4] drm/i915: check LVDS for EDID on GPU switches

[Ramkumar Ramachandra]

Chris Wilson wrote:
> On Tue, Jan 07, 2014 at 03:28:43PM +0530, Ramkumar Ramachandra wrote:
>> If the LVDS panel wasn't connected at boot then we won't have an EDID
>> for it. To fix this, call intel_lvds_get_edid() from the vga_switcheroo
>> reprobe callback.
>
> I would rather have an iterator over all our connectors (or perhaps
> encoders would be the right semantic, except we have
> connectors==encoders) and a reprobe callback.

I don't follow; iterate over which connectors? There's one
lvds_connector for which we get EDID.

> Saves exporting private
> functions and prevent me asking silly questions like what about eDP?

Avoid exporting intel_lvds_get_edid()? Why?

p.s- Excuse the stupidity of the questions; I know close to nothing
about how i915 or switcheroo 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 4/4] drm/i915: check LVDS for EDID on GPU switches

[Ramkumar Ramachandra]

Chris Wilson wrote:
> Rather than special casing lvds (especially when there are other panel
> connectors that can also be muxed), extend the connector interface to
> support a reprobe and walk over all connectors associated with i915
> after a switcheroo event.

Okay, so I can see the following get_edid functions:

  intel_lvds_get_edid()
  intel_crt_get_edid()
  intel_sdvo_get_edid()
  intel_dp_get_edid()

In the hdmi case, drm_get_edid() is called in two places:
intel_hdmi_detect() and intel_hdmi_detect_audio(); should I factor out
something into a corresponding intel_hdmi_get_edid() function?

Now, in i915_switcheroo_reprobe(), I need to call all these functions,
right? They all accept a a generic drm_connector and an specific
i2c_adapter. But how do I do that without exporting each of these
functions and their adapters?

Thanks.
--
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/4] Get EDID late for VGA switcheroo

[Ramkumar Ramachandra]

Seth Forshee wrote:
>  1. On many Macbook models the firmware isn't putting LVDS information
> in opregion. Reading the EDID during device initialization also
> fails since the DDC is muxed to the DGPU, so i915 concludes there's
> no LVDS and doesn't register an LVDS connector at all. I also think
> it was impossible to register a new connector at a later time,
> though I'm not sure about that.

On a different thread, Chris is helping me write a series to fill in
the switcheroo-reprobe callback with corresponding get-edid functions.
Do you think it'll be useful?

>  2. If i915 is forced to register the LVDS connector (say via a quirk)
> it still may not know the panel mode and guesses something rather
> conservative. This mode it assumes is used to allocate framebuffer
> memory, which is likely to end up being too small, and I don't think
> there was any support for resizing it later. This resulted in VTs
> not working because there isn't enough framebuffer memory for the
> mode they're trying to use.

I saw your quirk-patch (https://lkml.org/lkml/2012/8/4/128). Seems
like a rather inelegant approach to register the LVDS connector
unconditionally during initialization; I'll try to avoid going down
this road.

>  3. So what is really wanted is to be able to mux just the DDC over to
> the IGPU when the device is initialized to read the panel mode. One
> possible problem is that the hw might not support muxing the DDC
> separately, but Apple hw does so we'll ignore that for now. The
> basic code for muxing only the DDC isn't too difficult, and I had
> some patches for this at one point. The problem is that the handler
> must register with vga_switcheroo before this is possible, so
> there's a module initialization ordering issue that wasn't easily
> solved. Maybe now it would be possible to do something with
> EPROBE_DEFER, though I'm not sure how i915 would know whether or not
> it should wait for a switcheroo handler.

I didn't understand much of the above; I suppose it'll start making
sense when I'm deeper into the issue.

> I just didn't have enough time to spend on this issue to work through
> all of this. I also never looked at doing this with eDP, which is what I
> thought all the Macbooks have been using for the last couple of years.
> Are you sure your machine uses LVDS and not eDP?

I just assumed that it was LVDS; turns out it's eDP.

I have time to work on the issue now, so I'd appreciate any help I can get.
--
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 v2 1/4] drm/i915: add support for vga_switcheroo reprobe

[Ramkumar Ramachandra]

Cc: Andreas Heider 
Cc: Seth Forshee 
Original-patch-by: Andreas Heider 
Signed-off-by: Ramkumar Ramachandra 
---
 drivers/gpu/drm/i915/i915_dma.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5c64842..336a835b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1265,6 +1265,12 @@ static void i915_switcheroo_set_state(struct pci_dev 
*pdev, enum vga_switcheroo_
}
 }
 
+static void i915_switcheroo_reprobe(struct pci_dev *pdev)
+{
+   struct drm_device *dev = pci_get_drvdata(pdev);
+   intel_fbdev_output_poll_changed(dev);
+}
+
 static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
@@ -1278,7 +1284,7 @@ static bool i915_switcheroo_can_switch(struct pci_dev 
*pdev)
 
 static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
.set_gpu_state = i915_switcheroo_set_state,
-   .reprobe = NULL,
+   .reprobe = i915_switcheroo_reprobe,
.can_switch = i915_switcheroo_can_switch,
 };
 
-- 
1.8.5.2.229.g4448466

--
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/

[INCOMPLETE PATCH v2 0/4] Get EDID late for VGA switcheroo

[Ramkumar Ramachandra]

Hi Chris et al,

I got this far with creating a generic interface for various
get_edid() functions, but I'm stuck now. Where do I get the specific
i2c_adapter from?

I hope the series is okay otherwise.

Thanks.

Ramkumar Ramachandra (4):
  drm/i915: add support for vga_switcheroo reprobe
  drm/i915: factor out intel_lvds_get_edid()
  drm/i915: change intel_sdvo_get_edid() prototype
  drm/i915: introduce intel_connector->reprobe

 drivers/gpu/drm/i915/i915_dma.c   |   8 ++-
 drivers/gpu/drm/i915/intel_crt.c  |   1 +
 drivers/gpu/drm/i915/intel_dp.c   |   1 +
 drivers/gpu/drm/i915/intel_drv.h  |   6 +++
 drivers/gpu/drm/i915/intel_lvds.c | 101 ++
 drivers/gpu/drm/i915/intel_sdvo.c |  17 ---
 6 files changed, 84 insertions(+), 50 deletions(-)

-- 
1.8.5.2.229.g4448466

--
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/