* Re: [PATCH V2] tracing, perf : add cpu hotplug trace events
From: Frederic Weisbecker @ 2011-01-22 2:42 UTC (permalink / raw)
To: Vincent Guittot; +Cc: linux-kernel, linux-hotplug, rostedt, amit.kucheria
In-Reply-To: <AANLkTi=Tx3DYczwf9U=QS9XGs6C8sjKwVZr+RLuo781V@mail.gmail.com>
On Fri, Jan 21, 2011 at 06:41:58PM +0100, Vincent Guittot wrote:
> On 21 January 2011 17:44, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 09:43:18AM +0100, Vincent Guittot wrote:
> >> On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >> > On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
> >> >> Please find below a new proposal for adding trace events for cpu hotplug.
> >> >> The goal is to measure the latency of each part (kernel, architecture)
> >> >> and also to trace the cpu hotplug activity with other power events. I
> >> >> have tested these traces events on an arm platform.
> >> >>
> >> >> Changes since previous version:
> >> >> -Use cpu_hotplug for trace name
> >> >> -Define traces for kernel core and arch parts only
> >> >> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
> >> >> -Use proper indentation
> >> >>
> >> >> Subject: [PATCH] cpu hotplug tracepoint
> >> >>
> >> >> this patch adds new events for cpu hotplug tracing
> >> >> * plug/unplug sequence
> >> >> * core and architecture latency measurements
> >> >>
> >> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
> >> >> ---
> >> >> include/trace/events/cpu_hotplug.h | 117 ++++++++++++++++++++++++++++++++++++
> >> >
> >> > Note we can't apply new tracepoints if they are not inserted in the code.
> >>
> >> I agree, i just want to have 1st feedbacks on the tracepoint interface
> >> before providing a patch which inserts the trace in the code.
> >>
> >> >
> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
> >> >> +
> >> >> + TP_PROTO(unsigned int cpuid),
> >> >> +
> >> >> + TP_ARGS(cpuid)
> >> >> +);
> >> >> +
> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
> >> >> +
> >> >> + TP_PROTO(unsigned int cpuid),
> >> >> +
> >> >> + TP_ARGS(cpuid)
> >> >> +);
> >> >
> >> > What is wait die, compared to die for example?
> >> >
> >>
> >> The arch_wait_die is used to trace the process which waits for the cpu
> >> to die (__cpu_die) and the arch_die is used to trace when the cpu dies
> >> (cpu_die)
> >
> > I still can't find the difference.
> >
> > Having:
> >
> > trace_cpu_hotplug_arch_die_start(cpu)
> > __cpu_die();
> > trace_cpu_hotplug_arch_die_end(cpu)
> >
> > Is not enough to get both the information that a cpu dies
> > and the time took to do so?
> >
>
> it's quite interesting to trace the cpu_die function because the cpu
> really dies in this one.
Note in case of success, you have barely the same time between die and
wait_die, the difference will reside in some completion wait/polling,
noise, mostly. Probably most of the time unnoticeable and irrelevant.
Plus if you opt for this scheme, you need to put your die hook into
every architectures, while otherwise a simple trace_cpu_die_start()
trace_cpu_die_stop() pair around __cpu_die() call in the generic code
is enough.
> The __cpu_die function can't return if the
> cpu fails to die in the very last step and then wake up. But this
> could be detected with some cpu_die traces.
>
>
> for a normal use case we have something like :
> cpu 0 enters __cpu_die
> cpu 1 enters cpu_die
> cpu1 acks that it is going to died
> cpu0 returns from __cpu_die
>
> if the cpu 1 fails to die at the very last step, we could have:
> cpu 0 enters __cpu_die
> cpu 1 enters cpu_idle --> cpu_die
> cpu1 leaves cpu_die because of some issues and comes back into cpu_idle.
> cpu0 returns from __cpu_die after a timeout or an error ack
If it fails in the hardware level, you'll certainly notice in your
power profiling because a CPU is not supposed to take seconds to
die. Especially with a such visual tool like pytimechart, it will
be obvious.
For the details, that's something that must be found in syslogs and
that's it.
I don't think it's a good idea to handle such buggy and unexpected case at
the tracepoint level. You don't want to profile bugs, you want to debug them.
So it doesn't belong to this space IMHO.
> Then, cpu_die traces can be used with power traces for profiling the
> cpu power state. May be, the power.h trace file is a better place for
> the cpu_die traces ?
Hmm, this should probably stay inside the cpu hotplug tracepoint family,
this is where people will seek them in the first place.
^ permalink raw reply
* Re: [PATCH V2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-24 9:02 UTC (permalink / raw)
To: Frederic Weisbecker; +Cc: linux-kernel, linux-hotplug, rostedt, amit.kucheria
In-Reply-To: <20110122024229.GB2870@nowhere>
On 22 January 2011 03:42, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 06:41:58PM +0100, Vincent Guittot wrote:
>> On 21 January 2011 17:44, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 09:43:18AM +0100, Vincent Guittot wrote:
>> >> On 20 January 2011 17:11, Frederic Weisbecker <fweisbec@gmail.com> wrote:
>> >> > On Thu, Jan 20, 2011 at 09:25:54AM +0100, Vincent Guittot wrote:
>> >> >> Please find below a new proposal for adding trace events for cpu hotplug.
>> >> >> The goal is to measure the latency of each part (kernel, architecture)
>> >> >> and also to trace the cpu hotplug activity with other power events. I
>> >> >> have tested these traces events on an arm platform.
>> >> >>
>> >> >> Changes since previous version:
>> >> >> -Use cpu_hotplug for trace name
>> >> >> -Define traces for kernel core and arch parts only
>> >> >> -Use DECLARE_EVENT_CLASS and DEFINE_EVENT
>> >> >> -Use proper indentation
>> >> >>
>> >> >> Subject: [PATCH] cpu hotplug tracepoint
>> >> >>
>> >> >> this patch adds new events for cpu hotplug tracing
>> >> >> * plug/unplug sequence
>> >> >> * core and architecture latency measurements
>> >> >>
>> >> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.com>
>> >> >> ---
>> >> >> include/trace/events/cpu_hotplug.h | 117 ++++++++++++++++++++++++++++++++++++
>> >> >
>> >> > Note we can't apply new tracepoints if they are not inserted in the code.
>> >>
>> >> I agree, i just want to have 1st feedbacks on the tracepoint interface
>> >> before providing a patch which inserts the trace in the code.
>> >>
>> >> >
>> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_start,
>> >> >> +
>> >> >> + TP_PROTO(unsigned int cpuid),
>> >> >> +
>> >> >> + TP_ARGS(cpuid)
>> >> >> +);
>> >> >> +
>> >> >> +DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_wait_die_end,
>> >> >> +
>> >> >> + TP_PROTO(unsigned int cpuid),
>> >> >> +
>> >> >> + TP_ARGS(cpuid)
>> >> >> +);
>> >> >
>> >> > What is wait die, compared to die for example?
>> >> >
>> >>
>> >> The arch_wait_die is used to trace the process which waits for the cpu
>> >> to die (__cpu_die) and the arch_die is used to trace when the cpu dies
>> >> (cpu_die)
>> >
>> > I still can't find the difference.
>> >
>> > Having:
>> >
>> > trace_cpu_hotplug_arch_die_start(cpu)
>> > __cpu_die();
>> > trace_cpu_hotplug_arch_die_end(cpu)
>> >
>> > Is not enough to get both the information that a cpu dies
>> > and the time took to do so?
>> >
>>
>> it's quite interesting to trace the cpu_die function because the cpu
>> really dies in this one.
>
> Note in case of success, you have barely the same time between die and
> wait_die, the difference will reside in some completion wait/polling,
> noise, mostly. Probably most of the time unnoticeable and irrelevant.
>
OK, tracing only __cpu_die should be enough
> Plus if you opt for this scheme, you need to put your die hook into
> every architectures, while otherwise a simple trace_cpu_die_start()
> trace_cpu_die_stop() pair around __cpu_die() call in the generic code
> is enough.
>
>> The __cpu_die function can't return if the
>> cpu fails to die in the very last step and then wake up. But this
>> could be detected with some cpu_die traces.
>>
>>
>> for a normal use case we have something like :
>> cpu 0 enters __cpu_die
>> cpu 1 enters cpu_die
>> cpu1 acks that it is going to died
>> cpu0 returns from __cpu_die
>>
>> if the cpu 1 fails to die at the very last step, we could have:
>> cpu 0 enters __cpu_die
>> cpu 1 enters cpu_idle --> cpu_die
>> cpu1 leaves cpu_die because of some issues and comes back into cpu_idle.
>> cpu0 returns from __cpu_die after a timeout or an error ack
>
> If it fails in the hardware level, you'll certainly notice in your
> power profiling because a CPU is not supposed to take seconds to
> die. Especially with a such visual tool like pytimechart, it will
> be obvious.
>
> For the details, that's something that must be found in syslogs and
> that's it.
>
> I don't think it's a good idea to handle such buggy and unexpected case at
> the tracepoint level. You don't want to profile bugs, you want to debug them.
> So it doesn't belong to this space IMHO.
>
>> Then, cpu_die traces can be used with power traces for profiling the
>> cpu power state. May be, the power.h trace file is a better place for
>> the cpu_die traces ?
>
> Hmm, this should probably stay inside the cpu hotplug tracepoint family,
> this is where people will seek them in the first place.
>
^ permalink raw reply
* [PATCH V3 1/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-25 8:54 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria
Please find below a new proposal for adding trace events for cpu hotplug.
The goal is to measure the latency of each part (kernel, architecture)
and also to trace the cpu hotplug activity with other power events. I
have tested these traces events on an arm platform.
Subject: [PATCH 1/2] define cpu hotplug tracepoints
this patch adds new events for cpu hotplug tracing
* plug/unplug sequence
* core and architecture latency measurements
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
include/trace/events/cpu_hotplug.h | 103 ++++++++++++++++++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/cpu_hotplug.h
diff --git a/include/trace/events/cpu_hotplug.h
b/include/trace/events/cpu_hotplug.h
new file mode 100644
index 0000000..2a255e2
--- /dev/null
+++ b/include/trace/events/cpu_hotplug.h
@@ -0,0 +1,103 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cpu_hotplug
+
+#if !defined(_TRACE_CPU_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CPU_HOTPLUG_H
+
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(cpu_hotplug,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid),
+
+ TP_STRUCT__entry(
+ __field( unsigned int, cpuid )
+ ),
+
+ TP_fast_assign(
+ __entry->cpuid = cpuid;
+ ),
+
+ TP_printk("cpuid=%u", __entry->cpuid)
+);
+
+/* Core function of cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+/* Architecture function for cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_disable_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_disable_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_die_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_die_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+#endif /* _TRACE_CPU_HOTPLUG_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-25 8:54 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria
Please find below a new proposal for adding trace events for cpu hotplug.
The goal is to measure the latency of each part (kernel, architecture)
and also to trace the cpu hotplug activity with other power events. I
have tested these traces events on an arm platform.
Subject: [PATCH 1/2] add cpu hotplug tracepoints
this patch adds new events for cpu hotplug tracing
* plug/unplug sequence
* core and architecture latency measurements
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
kernel/cpu.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 156cc55..f04e9cf 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -16,6 +16,9 @@
#include <linux/mutex.h>
#include <linux/gfp.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/cpu_hotplug.h>
+
#ifdef CONFIG_SMP
/* Serializes the updates to cpu_online_mask, cpu_present_mask */
static DEFINE_MUTEX(cpu_add_remove_lock);
@@ -200,7 +203,9 @@ static int __ref take_cpu_down(void *_param)
int err;
/* Ensure this CPU doesn't handle any more interrupts. */
+ trace_cpu_hotplug_arch_disable_start((unsigned int)(param->hcpu));
err = __cpu_disable();
+ trace_cpu_hotplug_arch_disable_end((unsigned int)(param->hcpu));
if (err < 0)
return err;
@@ -256,7 +261,9 @@ static int __ref _cpu_down(unsigned int cpu, int
tasks_frozen)
cpu_relax();
/* This actually kills the CPU. */
+ trace_cpu_hotplug_arch_die_start(cpu);
__cpu_die(cpu);
+ trace_cpu_hotplug_arch_die_end(cpu);
/* CPU is completely dead: tell everyone. Too late to complain. */
cpu_notify_nofail(CPU_DEAD | mod, hcpu);
@@ -274,6 +281,8 @@ int __ref cpu_down(unsigned int cpu)
{
int err;
+ trace_cpu_hotplug_down_start(cpu);
+
cpu_maps_update_begin();
if (cpu_hotplug_disabled) {
@@ -285,6 +294,8 @@ int __ref cpu_down(unsigned int cpu)
out:
cpu_maps_update_done();
+
+ trace_cpu_hotplug_down_end(cpu);
return err;
}
EXPORT_SYMBOL(cpu_down);
@@ -310,7 +321,9 @@ static int __cpuinit _cpu_up(unsigned int cpu, int
tasks_frozen)
}
/* Arch-specific enabling code. */
+ trace_cpu_hotplug_arch_up_start(cpu);
ret = __cpu_up(cpu);
+ trace_cpu_hotplug_arch_up_end(cpu);
if (ret != 0)
goto out_notify;
BUG_ON(!cpu_online(cpu));
@@ -335,6 +348,8 @@ int __cpuinit cpu_up(unsigned int cpu)
pg_data_t *pgdat;
#endif
+ trace_cpu_hotplug_up_start(cpu);
+
if (!cpu_possible(cpu)) {
printk(KERN_ERR "can't online cpu %d because it is not "
"configured as may-hotadd at boot time\n", cpu);
@@ -376,6 +391,8 @@ int __cpuinit cpu_up(unsigned int cpu)
err = _cpu_up(cpu, 0);
+ trace_cpu_hotplug_up_end(cpu);
+
out:
cpu_maps_update_done();
return err;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-25 8:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=hQpCVJWZ_Op4mhnehufcBg2=h_=q4xXD66tGb@mail.gmail.com>
Please find below a new proposal for adding trace events for cpu hotplug.
The goal is to measure the latency of each part (kernel, architecture)
and also to trace the cpu hotplug activity with other power events. I
have tested these traces events on an arm platform.
Subject: [PATCH 2/2] add cpu hotplug tracepoints
this patch adds new events for cpu hotplug tracing
* plug/unplug sequence
* core and architecture latency measurements
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
kernel/cpu.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 156cc55..f04e9cf 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -16,6 +16,9 @@
#include <linux/mutex.h>
#include <linux/gfp.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/cpu_hotplug.h>
+
#ifdef CONFIG_SMP
/* Serializes the updates to cpu_online_mask, cpu_present_mask */
static DEFINE_MUTEX(cpu_add_remove_lock);
@@ -200,7 +203,9 @@ static int __ref take_cpu_down(void *_param)
int err;
/* Ensure this CPU doesn't handle any more interrupts. */
+ trace_cpu_hotplug_arch_disable_start((unsigned int)(param->hcpu));
err = __cpu_disable();
+ trace_cpu_hotplug_arch_disable_end((unsigned int)(param->hcpu));
if (err < 0)
return err;
@@ -256,7 +261,9 @@ static int __ref _cpu_down(unsigned int cpu, int
tasks_frozen)
cpu_relax();
/* This actually kills the CPU. */
+ trace_cpu_hotplug_arch_die_start(cpu);
__cpu_die(cpu);
+ trace_cpu_hotplug_arch_die_end(cpu);
/* CPU is completely dead: tell everyone. Too late to complain. */
cpu_notify_nofail(CPU_DEAD | mod, hcpu);
@@ -274,6 +281,8 @@ int __ref cpu_down(unsigned int cpu)
{
int err;
+ trace_cpu_hotplug_down_start(cpu);
+
cpu_maps_update_begin();
if (cpu_hotplug_disabled) {
@@ -285,6 +294,8 @@ int __ref cpu_down(unsigned int cpu)
out:
cpu_maps_update_done();
+
+ trace_cpu_hotplug_down_end(cpu);
return err;
}
EXPORT_SYMBOL(cpu_down);
@@ -310,7 +321,9 @@ static int __cpuinit _cpu_up(unsigned int cpu, int
tasks_frozen)
}
/* Arch-specific enabling code. */
+ trace_cpu_hotplug_arch_up_start(cpu);
ret = __cpu_up(cpu);
+ trace_cpu_hotplug_arch_up_end(cpu);
if (ret != 0)
goto out_notify;
BUG_ON(!cpu_online(cpu));
@@ -335,6 +348,8 @@ int __cpuinit cpu_up(unsigned int cpu)
pg_data_t *pgdat;
#endif
+ trace_cpu_hotplug_up_start(cpu);
+
if (!cpu_possible(cpu)) {
printk(KERN_ERR "can't online cpu %d because it is not "
"configured as may-hotadd at boot time\n", cpu);
@@ -376,6 +391,8 @@ int __cpuinit cpu_up(unsigned int cpu)
err = _cpu_up(cpu, 0);
+ trace_cpu_hotplug_up_end(cpu);
+
out:
cpu_maps_update_done();
return err;
--
1.7.1
^ permalink raw reply related
* [PATCH] udev: add rules for qemu guests
From: Gerd Hoffmann @ 2011-01-25 10:44 UTC (permalink / raw)
To: linux-hotplug
These patches enable usb autosuspend for the qemu emulated HID devices.
This reduces the cpu load for idle guests with a hid device attached
because the linux kernel will suspend the usb bus then and qemu can stop
running a 1000 Hz to emulate the (active) UHCI controller.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
Makefile.am | 6 ++++++
| 12 ++++++++++++
| 7 +++++++
3 files changed, 25 insertions(+), 0 deletions(-)
create mode 100644 extras/qemu/99-qemu-usb.rules
create mode 100755 extras/qemu/qemu-usb-autosuspend
diff --git a/Makefile.am b/Makefile.am
index 2e3fe39..c09b2a0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -317,6 +317,12 @@ extras_v4l_id_v4l_id_LDADD = libudev/libudev-private.la
libexec_PROGRAMS += extras/v4l_id/v4l_id
dist_udevrules_DATA += extras/v4l_id/60-persistent-v4l.rules
+# ------------------------------------------------------------------------------
+# qemu -- qemu/kvm guest tweaks
+# ------------------------------------------------------------------------------
+dist_udevrules_DATA += extras/qemu/99-qemu-usb.rules
+dist_libexec_SCRIPTS += extras/qemu/qemu-usb-autosuspend
+
if ENABLE_EXTRAS
# ------------------------------------------------------------------------------
# conditional extras (need glib, libusb, libacl, ...)
--git a/extras/qemu/99-qemu-usb.rules b/extras/qemu/99-qemu-usb.rules
new file mode 100644
index 0000000..35f33e1
--- /dev/null
+++ b/extras/qemu/99-qemu-usb.rules
@@ -0,0 +1,12 @@
+#
+# Enable autosuspend for qemu emulated usb hid devices.
+#
+# Note that there are buggy qemu versions which advertise remote
+# wakeup support but don't actually implement it correctly. This
+# is the reason why we need a match for the serial number here.
+# The serial number "42" is used to tag the implementations where
+# remote wakeup is working.
+#
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", RUN+="qemu-usb-autosuspend %p"
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Tablet", ATTR{serial}="42", RUN+="qemu-usb-autosuspend %p"
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Keyboard", ATTR{serial}="42", RUN+="qemu-usb-autosuspend %p"
--git a/extras/qemu/qemu-usb-autosuspend b/extras/qemu/qemu-usb-autosuspend
new file mode 100755
index 0000000..48761de
--- /dev/null
+++ b/extras/qemu/qemu-usb-autosuspend
@@ -0,0 +1,7 @@
+#!/bin/sh
+path="$1"
+if test -f "/sys${path}/power/control"; then
+ echo "auto" > "/sys${path}/power/control"
+elif test -f "/sys${path}/power/level"; then
+ echo "auto" > "/sys${path}/power/level"
+fi
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] udev: add rules for qemu guests
From: Kay Sievers @ 2011-01-25 12:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295952245-3038-1-git-send-email-kraxel@redhat.com>
On Tue, Jan 25, 2011 at 11:44, Gerd Hoffmann <kraxel@redhat.com> wrote:
> These patches enable usb autosuspend for the qemu emulated HID devices.
> This reduces the cpu load for idle guests with a hid device attached
> because the linux kernel will suspend the usb bus then and qemu can stop
> running a 1000 Hz to emulate the (active) UHCI controller.
I guess this should go into the qemu package, not the udev sources.
Kay
^ permalink raw reply
* Re: [PATCH] udev: add rules for qemu guests
From: Gerd Hoffmann @ 2011-01-25 12:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295952245-3038-1-git-send-email-kraxel@redhat.com>
On 01/25/11 13:01, Kay Sievers wrote:
> On Tue, Jan 25, 2011 at 11:44, Gerd Hoffmann<kraxel@redhat.com> wrote:
>> These patches enable usb autosuspend for the qemu emulated HID devices.
>> This reduces the cpu load for idle guests with a hid device attached
>> because the linux kernel will suspend the usb bus then and qemu can stop
>> running a 1000 Hz to emulate the (active) UHCI controller.
>
> I guess this should go into the qemu package, not the udev sources.
Well, this should be installed in a *guest*, whereas qemu itself is
installed on the virtualization *host*. Placing it in the qemu package
would have no effect at all ;)
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH] udev: add rules for qemu guests
From: Kay Sievers @ 2011-01-25 13:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295952245-3038-1-git-send-email-kraxel@redhat.com>
On Tue, Jan 25, 2011 at 11:44, Gerd Hoffmann <kraxel@redhat.com> wrote:
> These patches enable usb autosuspend for the qemu emulated HID devices.
> This reduces the cpu load for idle guests with a hid device attached
> because the linux kernel will suspend the usb bus then and qemu can stop
> running a 1000 Hz to emulate the (active) UHCI controller.
> +dist_udevrules_DATA += extras/qemu/99-qemu-usb.rules
The number should be 10-90 for the default things, or is there a
dependency on anything else?
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", RUN+="qemu-usb-autosuspend %p"
This should probably be a simple ATTR{power/control}="auto"
> --- /dev/null
> +++ b/extras/qemu/qemu-usb-autosuspend
> @@ -0,0 +1,7 @@
> +#!/bin/sh
If possible, we try to avoid shell scripts.
> +path="$1"
> +if test -f "/sys${path}/power/control"; then
> + echo "auto" > "/sys${path}/power/control"
> +elif test -f "/sys${path}/power/level"; then
> + echo "auto" > "/sys${path}/power/level"
> +fi
Which one is the actual one? Is the second try only for older kernels?
That could go in the compat rules, udev does not ship rules for older
kernels in the default installation.
Anyway, why isn't all this done in the kernel? Can't this be made
working somehow?
Carrying out configuration, and unconditionally applying it from udev
rules, should be avoided if possible and if the kernel could do it
itself. We ran into serious issues in the past when more recent
kernels did not like the config anymore that udev applied.
Cheers,
Kay
^ permalink raw reply
* Re: [PATCH] udev: add rules for qemu guests
From: Gerd Hoffmann @ 2011-01-25 14:07 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295952245-3038-1-git-send-email-kraxel@redhat.com>
On 01/25/11 14:39, Kay Sievers wrote:
> On Tue, Jan 25, 2011 at 11:44, Gerd Hoffmann<kraxel@redhat.com> wrote:
>> These patches enable usb autosuspend for the qemu emulated HID devices.
>> This reduces the cpu load for idle guests with a hid device attached
>> because the linux kernel will suspend the usb bus then and qemu can stop
>> running a 1000 Hz to emulate the (active) UHCI controller.
>
>> +dist_udevrules_DATA += extras/qemu/99-qemu-usb.rules
>
> The number should be 10-90 for the default things, or is there a
> dependency on anything else?
No dependency at all. What number do you suggest then?
>> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", RUN+="qemu-usb-autosuspend %p"
>
> This should probably be a simple ATTR{power/control}="auto"
That should work indeed. Didn't know you can write sysfs files that way.
>> +path="$1"
>> +if test -f "/sys${path}/power/control"; then
>> + echo "auto"> "/sys${path}/power/control"
>> +elif test -f "/sys${path}/power/level"; then
>> + echo "auto"> "/sys${path}/power/level"
>> +fi
>
> Which one is the actual one? Is the second try only for older kernels?
Yes, it is for older kernels.
> That could go in the compat rules, udev does not ship rules for older
> kernels in the default installation.
Ok. Is there some way to express "power/control doesn't exist but
power/level does" as udev rule, so I can zap the shell script?
> Anyway, why isn't all this done in the kernel? Can't this be made
> working somehow?
As far I know the kernel doesn't do that by default because too much
broken hardware is out there which breaks when autosuspend is enabled by
default. I saw mentioned somewhere the plan is to have udev enable this
for known-good devices, so I'm trying that route :)
Havn't checked whenever there is a in-kernel white list for that stuff
which could be used instead.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH] udev: add rules for qemu guests
From: Kay Sievers @ 2011-01-25 14:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295952245-3038-1-git-send-email-kraxel@redhat.com>
On Tue, Jan 25, 2011 at 15:07, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On 01/25/11 14:39, Kay Sievers wrote:
>>> +dist_udevrules_DATA += extras/qemu/99-qemu-usb.rules
>>
>> The number should be 10-90 for the default things, or is there a
>> dependency on anything else?
>
> No dependency at all. What number do you suggest then?
Doesn't really matter, we just leave 00-09 and 91-99 for other custom
stuff, to get easily before and after the common things.
>> That could go in the compat rules, udev does not ship rules for older
>> kernels in the default installation.
>
> Ok. Is there some way to express "power/control doesn't exist but
> power/level does" as udev rule, so I can zap the shell script?
TEST="" should do that.
>> Anyway, why isn't all this done in the kernel? Can't this be made
>> working somehow?
>
> As far I know the kernel doesn't do that by default because too much broken
> hardware is out there which breaks when autosuspend is enabled by default.
Yeah, there is a reason not to do that for all devices, there are too
many broken ones.
> I saw mentioned somewhere the plan is to have udev enable this for
> known-good devices, so I'm trying that route :)
Oh, yeah, nice idea. That's the reason there is no list at all. :)
> Havn't checked whenever there is a in-kernel white list for that stuff which
> could be used instead.
Yeah, would be nice to have some generic way to enable autosuspend
when the hardware (real or emulated one) hints that it supports that.
Not sure how it would look like in detail though.
Kay
^ permalink raw reply
* Re: [PATCH] udev: add rules for qemu guests
From: Gerd Hoffmann @ 2011-01-25 14:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295952245-3038-1-git-send-email-kraxel@redhat.com>
Hi,
>> No dependency at all. What number do you suggest then?
>
> Doesn't really matter, we just leave 00-09 and 91-99 for other custom
> stuff, to get easily before and after the common things.
Fine, so I can pick '42' ;)
>> Ok. Is there some way to express "power/control doesn't exist but
>> power/level does" as udev rule, so I can zap the shell script?
>
> TEST="" should do that.
Thanks.
>> Havn't checked whenever there is a in-kernel white list for that stuff which
>> could be used instead.
>
> Yeah, would be nice to have some generic way to enable autosuspend
> when the hardware (real or emulated one) hints that it supports that.
Well, there is a descriptor bit for that of course, but unfortunately
one can't expect that only (physical or virtual) devices without bugs
actually set that ...
cheers,
Gerd
^ permalink raw reply
* [PATCH v2] udev: add rules for qemu guests
From: Gerd Hoffmann @ 2011-01-25 14:51 UTC (permalink / raw)
To: linux-hotplug
These patches enable usb autosuspend for the qemu emulated HID devices.
This reduces the cpu load for idle guests with a hid device attached
because the linux kernel will suspend the usb bus then and qemu can stop
running a 1000 Hz to emulate the (active) UHCI controller.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
Makefile.am | 5 +++++
| 13 +++++++++++++
rules/misc/30-kernel-compat.rules | 5 +++++
3 files changed, 23 insertions(+), 0 deletions(-)
create mode 100644 extras/qemu/42-qemu-usb.rules
diff --git a/Makefile.am b/Makefile.am
index 2e3fe39..b2300ce 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -317,6 +317,11 @@ extras_v4l_id_v4l_id_LDADD = libudev/libudev-private.la
libexec_PROGRAMS += extras/v4l_id/v4l_id
dist_udevrules_DATA += extras/v4l_id/60-persistent-v4l.rules
+# ------------------------------------------------------------------------------
+# qemu -- qemu/kvm guest tweaks
+# ------------------------------------------------------------------------------
+dist_udevrules_DATA += extras/qemu/99-qemu-usb.rules
+
if ENABLE_EXTRAS
# ------------------------------------------------------------------------------
# conditional extras (need glib, libusb, libacl, ...)
--git a/extras/qemu/42-qemu-usb.rules b/extras/qemu/42-qemu-usb.rules
new file mode 100644
index 0000000..4fd53c7
--- /dev/null
+++ b/extras/qemu/42-qemu-usb.rules
@@ -0,0 +1,13 @@
+#
+# Enable autosuspend for qemu emulated usb hid devices.
+#
+# Note that there are buggy qemu versions which advertise remote
+# wakeup support but don't actually implement it correctly. This
+# is the reason why we need a match for the serial number here.
+# The serial number "42" is used to tag the implementations where
+# remote wakeup is working.
+#
+
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Tablet", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
+CTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Keyboard", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
diff --git a/rules/misc/30-kernel-compat.rules b/rules/misc/30-kernel-compat.rules
index 2c545dc..2a6a97c 100644
--- a/rules/misc/30-kernel-compat.rules
+++ b/rules/misc/30-kernel-compat.rules
@@ -97,4 +97,9 @@ SUBSYSTEM="mmc", RUN+="/sbin/modprobe -b mmc_block"
SUBSYSTEM="pnp", DRIVER!="?*", \
RUN{ignore_error}+="/bin/sh -c '/sbin/modprobe -a $$(while read id; do echo pnp:d$$id; done < /sys$devpath/id)'"
+# see extras/qemu/42-qemu-usb.rules, version for 2.6.32 + older.
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", TEST="power/level", ATTR{power/level}="auto"
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Tablet", ATTR{serial}="42", TEST="power/level", ATTR{power/level}="auto"
+ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Keyboard", ATTR{serial}="42", TEST="power/level", ATTR{power/level}="auto"
+
LABEL="kernel_compat_end"
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v2] udev: add rules for qemu guests
From: Kay Sievers @ 2011-01-25 15:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295967067-18479-1-git-send-email-kraxel@redhat.com>
On Tue, Jan 25, 2011 at 15:51, Gerd Hoffmann <kraxel@redhat.com> wrote:
> These patches enable usb autosuspend for the qemu emulated HID devices.
> This reduces the cpu load for idle guests with a hid device attached
> because the linux kernel will suspend the usb bus then and qemu can stop
> running a 1000 Hz to emulate the (active) UHCI controller.
Applied.
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH v2] udev: add rules for qemu guests
From: Ozan Çağlayan @ 2011-01-25 18:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295967067-18479-1-git-send-email-kraxel@redhat.com>
On 25.01.2011 16:51, Gerd Hoffmann wrote:
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Tablet", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
> +CTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Keyboard", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
There's a typo in here.
--
Pardus Linux
http://www.pardus.org.tr/eng
^ permalink raw reply
* how to suppress write_net_rules (prevent alteration of my net rules)
From: John Lumby @ 2011-01-25 19:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <COL116-W182958BE507DDC0AD7E74DA3F60@phx.gbl>
Thanks Andrey :
On Thu, 20 Jan 2011 at 21:50:29 Andrey Borzenkov wrote:
>
> Either you have really old udev version or your distribution installs
> standard rules under /etc instead of under /lib. In both cases you
> probably need to ask your distro about it.
>
It is current version but my distro is many times upgraded from the original old one and that file must have remained behind or been restored. I've now saved it and replaced by Kay's comment-line.
> > Andrey Borzenkov wrote:
>
> No, it won't.
>
> Just continue to use the same rules for KERNEL != "eth0" as you use now.
>
Ah - now I get it - add that as an extra rule at the start of the rules to catch the case of which ever device is currently eth0 (if any). Ok - thanks.
John
^ permalink raw reply
* Re: [PATCH v2] udev: add rules for qemu guests
From: Kay Sievers @ 2011-01-25 20:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295967067-18479-1-git-send-email-kraxel@redhat.com>
On Tue, Jan 25, 2011 at 19:43, Ozan Çağlayan <ozan@pardus.org.tr> wrote:
> On 25.01.2011 16:51, Gerd Hoffmann wrote:
>
>> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse",
>> ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
>> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Tablet",
>> ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
>> +CTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Keyboard",
>> ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
>
> There's a typo in here.
Fixed.
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH v2] udev: add rules for qemu guests
From: Jim Paris @ 2011-01-26 4:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1295967067-18479-1-git-send-email-kraxel@redhat.com>
Gerd Hoffmann wrote:
> These patches enable usb autosuspend for the qemu emulated HID devices.
> This reduces the cpu load for idle guests with a hid device attached
> because the linux kernel will suspend the usb bus then and qemu can stop
> running a 1000 Hz to emulate the (active) UHCI controller.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> Makefile.am | 5 +++++
> extras/qemu/42-qemu-usb.rules | 13 +++++++++++++
> rules/misc/30-kernel-compat.rules | 5 +++++
> 3 files changed, 23 insertions(+), 0 deletions(-)
> create mode 100644 extras/qemu/42-qemu-usb.rules
>
> diff --git a/Makefile.am b/Makefile.am
> index 2e3fe39..b2300ce 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -317,6 +317,11 @@ extras_v4l_id_v4l_id_LDADD = libudev/libudev-private.la
> libexec_PROGRAMS += extras/v4l_id/v4l_id
> dist_udevrules_DATA += extras/v4l_id/60-persistent-v4l.rules
>
> +# ------------------------------------------------------------------------------
> +# qemu -- qemu/kvm guest tweaks
> +# ------------------------------------------------------------------------------
> +dist_udevrules_DATA += extras/qemu/99-qemu-usb.rules
That should be 42-qemu-usb.rules
-jim
> +
> if ENABLE_EXTRAS
> # ------------------------------------------------------------------------------
> # conditional extras (need glib, libusb, libacl, ...)
> diff --git a/extras/qemu/42-qemu-usb.rules b/extras/qemu/42-qemu-usb.rules
> new file mode 100644
> index 0000000..4fd53c7
> --- /dev/null
> +++ b/extras/qemu/42-qemu-usb.rules
> @@ -0,0 +1,13 @@
> +#
> +# Enable autosuspend for qemu emulated usb hid devices.
> +#
> +# Note that there are buggy qemu versions which advertise remote
> +# wakeup support but don't actually implement it correctly. This
> +# is the reason why we need a match for the serial number here.
> +# The serial number "42" is used to tag the implementations where
> +# remote wakeup is working.
> +#
> +
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Tablet", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
> +CTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Keyboard", ATTR{serial}="42", TEST="power/control", ATTR{power/control}="auto"
> diff --git a/rules/misc/30-kernel-compat.rules b/rules/misc/30-kernel-compat.rules
> index 2c545dc..2a6a97c 100644
> --- a/rules/misc/30-kernel-compat.rules
> +++ b/rules/misc/30-kernel-compat.rules
> @@ -97,4 +97,9 @@ SUBSYSTEM="mmc", RUN+="/sbin/modprobe -b mmc_block"
> SUBSYSTEM="pnp", DRIVER!="?*", \
> RUN{ignore_error}+="/bin/sh -c '/sbin/modprobe -a $$(while read id; do echo pnp:d$$id; done < /sys$devpath/id)'"
>
> +# see extras/qemu/42-qemu-usb.rules, version for 2.6.32 + older.
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Mouse", ATTR{serial}="42", TEST="power/level", ATTR{power/level}="auto"
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Tablet", ATTR{serial}="42", TEST="power/level", ATTR{power/level}="auto"
> +ACTION="add", SUBSYSTEM="usb", ATTR{product}="QEMU USB Keyboard", ATTR{serial}="42", TEST="power/level", ATTR{power/level}="auto"
> +
> LABEL="kernel_compat_end"
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] tracing, perf : add cpu hotplug trace events
From: Frederic Weisbecker @ 2011-01-26 17:32 UTC (permalink / raw)
To: Vincent Guittot; +Cc: linux-kernel, linux-hotplug, rostedt, amit.kucheria
In-Reply-To: <AANLkTi=hQpCVJWZ_Op4mhnehufcBg2=h_=q4xXD66tGb@mail.gmail.com>
On Tue, Jan 25, 2011 at 09:54:59AM +0100, Vincent Guittot wrote:
> Please find below a new proposal for adding trace events for cpu hotplug.
> The goal is to measure the latency of each part (kernel, architecture)
> and also to trace the cpu hotplug activity with other power events. I
> have tested these traces events on an arm platform.
>
> Subject: [PATCH 1/2] add cpu hotplug tracepoints
>
> this patch adds new events for cpu hotplug tracing
> * plug/unplug sequence
> * core and architecture latency measurements
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/cpu.c | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 156cc55..f04e9cf 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -16,6 +16,9 @@
> #include <linux/mutex.h>
> #include <linux/gfp.h>
>
> +#define CREATE_TRACE_POINTS
> +#include <trace/events/cpu_hotplug.h>
> +
> #ifdef CONFIG_SMP
> /* Serializes the updates to cpu_online_mask, cpu_present_mask */
> static DEFINE_MUTEX(cpu_add_remove_lock);
> @@ -200,7 +203,9 @@ static int __ref take_cpu_down(void *_param)
> int err;
>
> /* Ensure this CPU doesn't handle any more interrupts. */
> + trace_cpu_hotplug_arch_disable_start((unsigned int)(param->hcpu));
> err = __cpu_disable();
> + trace_cpu_hotplug_arch_disable_end((unsigned int)(param->hcpu));
You should create a cpu var instead of doing that not very beautiful cast
twice.
Probably we should eventually rename arch_disable into just disable.
And same for die, because otherwise the name is quite long.
Other than that, looks all good to me.
Thanks.
^ permalink raw reply
* biosdevname v0.3.6
From: Matt Domsch @ 2011-01-26 19:18 UTC (permalink / raw)
To: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Co
biosdevname, now version 0.3.6.
(0.3.5 was a dud due to a change in gcc/libtool that broke building
the static copy. https://bugzilla.redhat.com/show_bug.cgi?idg2689)
this fixes the udev rules, such that biosdevname is not invoked if an
earlier rule (such as 70-persistent-net.rules) sets a name. this has
been the intended behavior, but was missed until now.
furthermore, /usr/sbin/dump_pirq was added as a debugging aid, the
static copy biosdevnames is no longer built (it was originally
intended for use inside fairly limited initrd environments, but was
never really used there, and with dracut is now unnecessary),
and it checks if you're running as root, as it needs root to read
SMBIOS and PCI IRQ Routing Table information.
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.6.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.6.tar.gz.sign
git://linux.dell.com/biosdevname.git
I built this yesterday for Fedora rawhide (will be 15), and I encourage
other distributions to pick it up as well.
There is a Fedora Test Day tomorrow (Thursday)
https://fedoraproject.org/wiki/Test_Day:2011-01-27_Network_Device_Naming_With_Biosdevname
and I encourage you to give this a try and report success/failures as
noted here.
There has also been a good bit of blog coverage over the last few
days, with thanks to Joe Brockmeier.
http://www.networkworld.com/community/fedora-15-changes-network-device-naming
shortlog:
Matt Domsch (13):
add check for running as root, exit if not
add exit code 3 to manpage
udev rules: skip if NAME is already set
build dump_pirq, minimizing library linking
install dump_pirq into /usr/sbin/
install dump_pirq in debs too
update changelogs, bump version
move udev rules file into /lib/udev/rules.d
update changelog
add TODO
automatically determine which dir the rules file goes
drop biosdevnameS, it's unused and fails to build on F15
bump version
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH 2/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-27 10:04 UTC (permalink / raw)
To: Frederic Weisbecker; +Cc: linux-kernel, linux-hotplug, rostedt, amit.kucheria
In-Reply-To: <20110126173241.GD1757@nowhere>
On 26 January 2011 18:32, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Tue, Jan 25, 2011 at 09:54:59AM +0100, Vincent Guittot wrote:
>> Please find below a new proposal for adding trace events for cpu hotplug.
>> The goal is to measure the latency of each part (kernel, architecture)
>> and also to trace the cpu hotplug activity with other power events. I
>> have tested these traces events on an arm platform.
>>
>> Subject: [PATCH 1/2] add cpu hotplug tracepoints
>>
>> this patch adds new events for cpu hotplug tracing
>> * plug/unplug sequence
>> * core and architecture latency measurements
>>
>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>> ---
>> kernel/cpu.c | 17 +++++++++++++++++
>> 1 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index 156cc55..f04e9cf 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -16,6 +16,9 @@
>> #include <linux/mutex.h>
>> #include <linux/gfp.h>
>>
>> +#define CREATE_TRACE_POINTS
>> +#include <trace/events/cpu_hotplug.h>
>> +
>> #ifdef CONFIG_SMP
>> /* Serializes the updates to cpu_online_mask, cpu_present_mask */
>> static DEFINE_MUTEX(cpu_add_remove_lock);
>> @@ -200,7 +203,9 @@ static int __ref take_cpu_down(void *_param)
>> int err;
>>
>> /* Ensure this CPU doesn't handle any more interrupts. */
>> + trace_cpu_hotplug_arch_disable_start((unsigned int)(param->hcpu));
>> err = __cpu_disable();
>> + trace_cpu_hotplug_arch_disable_end((unsigned int)(param->hcpu));
>
> You should create a cpu var instead of doing that not very beautiful cast
> twice.
>
OK
> Probably we should eventually rename arch_disable into just disable.
>
> And same for die, because otherwise the name is quite long.
>
If we remove the arch extension of these names, we will have
trace_cpu_hotplug_arch_up for __cpu_up (trace_cpu_hotplug_up is
already used) and trace_cpu_hotplug_disable for __cpu_disable. would
that be acceptable ?
> Other than that, looks all good to me.
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH 2/2] tracing, perf : add cpu hotplug trace events
From: Frederic Weisbecker @ 2011-01-28 17:54 UTC (permalink / raw)
To: Vincent Guittot; +Cc: linux-kernel, linux-hotplug, rostedt, amit.kucheria
In-Reply-To: <AANLkTikEvEyMZgmCozw_yt1enRJ2+GTvd02BY30hUJt0@mail.gmail.com>
On Thu, Jan 27, 2011 at 11:04:09AM +0100, Vincent Guittot wrote:
> On 26 January 2011 18:32, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > On Tue, Jan 25, 2011 at 09:54:59AM +0100, Vincent Guittot wrote:
> >> Please find below a new proposal for adding trace events for cpu hotplug.
> >> The goal is to measure the latency of each part (kernel, architecture)
> >> and also to trace the cpu hotplug activity with other power events. I
> >> have tested these traces events on an arm platform.
> >>
> >> Subject: [PATCH 1/2] add cpu hotplug tracepoints
> >>
> >> this patch adds new events for cpu hotplug tracing
> >> * plug/unplug sequence
> >> * core and architecture latency measurements
> >>
> >> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> >> ---
> >> kernel/cpu.c | 17 +++++++++++++++++
> >> 1 files changed, 17 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/kernel/cpu.c b/kernel/cpu.c
> >> index 156cc55..f04e9cf 100644
> >> --- a/kernel/cpu.c
> >> +++ b/kernel/cpu.c
> >> @@ -16,6 +16,9 @@
> >> #include <linux/mutex.h>
> >> #include <linux/gfp.h>
> >>
> >> +#define CREATE_TRACE_POINTS
> >> +#include <trace/events/cpu_hotplug.h>
> >> +
> >> #ifdef CONFIG_SMP
> >> /* Serializes the updates to cpu_online_mask, cpu_present_mask */
> >> static DEFINE_MUTEX(cpu_add_remove_lock);
> >> @@ -200,7 +203,9 @@ static int __ref take_cpu_down(void *_param)
> >> int err;
> >>
> >> /* Ensure this CPU doesn't handle any more interrupts. */
> >> + trace_cpu_hotplug_arch_disable_start((unsigned int)(param->hcpu));
> >> err = __cpu_disable();
> >> + trace_cpu_hotplug_arch_disable_end((unsigned int)(param->hcpu));
> >
> > You should create a cpu var instead of doing that not very beautiful cast
> > twice.
> >
>
> OK
>
> > Probably we should eventually rename arch_disable into just disable.
> >
> > And same for die, because otherwise the name is quite long.
> >
>
> If we remove the arch extension of these names, we will have
> trace_cpu_hotplug_arch_up for __cpu_up (trace_cpu_hotplug_up is
> already used) and trace_cpu_hotplug_disable for __cpu_disable. would
> that be acceptable ?
You're right.
Well, we could rename cpu_hotplug_arch_up into cpu_hotplug_enable,
but the overall result makes it confusing.
Let's keep it that way.
^ permalink raw reply
* Re: net device renaming 2-step, IFNAMSIZ limit
From: Matt Domsch @ 2011-01-29 15:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101129032908.GA29904@auslistsprd01.us.dell.com>
On Tue, Dec 07, 2010 at 12:45:04AM -0200, Piter PUNK wrote:
> Matt Domsch wrote:
> >I see this in the udev debug logs when using biosdevname (which I
> >finally got working with SR-IOV devices tonight):
> >
> >renamed network interface eth60 to eth60-pci2#0_60
> >renamed network interface eth60-pci2#0_60 to pci2#0_60
> >
> >So, it worked, however, note that the rename happens in 2 steps, the
> >middle step of which uses a name that's dangerously close to
> >IFNAMSIZ, in fact it is 15 chars there.
> >
> ><...>
> >
> >I need a solution in which the intermediate name doesn't exceed 15
> >characters, and is guaranteed to be unique, as there may be lots of
> >udev instances running in parallel trying to do the same thing.
> >
> >Ideas?
>
> As we talk on #udev, there is a patch that uses hash32 function inside
> libudev to create
> the intermediate name. We use the "oldname-newname" to create the hash.
> With that,
> exceeding IFNAMSIZ isn't a problem:
Piter's patch works for me, and I need this in udev fairly quickly
please. Some kind folks from IBM have been testing biosdevname with
quad-port Intel SR-IOV-capable devices, and instantiating all the VFs,
can easily have >100 eth* devices created in the kernel
instantaneously. That bumps step 1 in the 2-step rename operation
over IFNAMSIZ (eth100-pci2#3_62 is 16 chars).
Please apply. I'm re-pasting from the original email for convenience.
Tested-by: Matt Domsch <Matt_Domsch@dell.com>
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
diff --git a/udev/udev-event.c b/udev/udev-event.c
index 0648735..5387c00 100644
--- a/udev/udev-event.c
+++ b/udev/udev-event.c
@@ -462,6 +462,7 @@ static void rename_netif_kernel_log(struct ifreq ifr)
static int rename_netif(struct udev_event *event)
{
struct udev_device *dev = event->dev;
+ char iftmp[IFNAMSIZ];
int sk;
struct ifreq ifr;
int loop;
@@ -492,7 +493,8 @@ static int rename_netif(struct udev_event *event)
goto out;
/* free our own name, another process may wait for us */
- util_strscpyl(ifr.ifr_newname, IFNAMSIZ, udev_device_get_sysname(dev), "-", event->name, NULL);
+ util_strscpyl(iftmp, IFNAMSIZ, udev_device_get_sysname(dev), "-", event->name, NULL);
+ sprintf(ifr.ifr_newname, "eth_%X",util_string_hash32(iftmp));
err = ioctl(sk, SIOCSIFNAME, &ifr);
if (err < 0) {
err = -errno;
^ permalink raw reply related
* Blog coverage of Consistent Network Device Naming
From: Matt Domsch @ 2011-01-30 14:23 UTC (permalink / raw)
To: linux-hotplug, netdev
There has been a good bit of blog coverage over the Consistent Network
Device Naming (biosdevname) feature this past week. If you're curious:
A Lesson In Persistency by Rahul Sundaram
http://fedoranext.wordpress.com/2010/12/07/a-lesson-in-persistency
NetworkWorld 2011-01-24 by Joe Brockmeier
http://www.networkworld.com/community/fedora-15-changes-network-device-naming
Matt Domsch's blog and repost on dell.com
http://domsch.com/blog/?pE5 2011-01-23
http://en.community.dell.com/dell-blogs/enterprise/b/tech-center/archive/2011/01/24/consistent-network-device-naming-coming-to-fedora-15.aspx
LWN.net
http://lwn.net/Articles/424859/#Comments
Slashdot
http://linux.slashdot.org/story/11/01/26/0252220/Fedora-15-Changes-Network-Device-Naming-Scheme
Digitizor
http://digitizor.com/2011/01/25/fedora-15-network-device-naming/ Digitizor 2011-01-25
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [PATCH V4 1/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-01-31 10:22 UTC (permalink / raw)
To: linux-kernel, linux-hotplug, fweisbec, rostedt, amit.kucheria
Please find below a new proposal for adding trace events for cpu hotplug.
The goal is to measure the latency of each part (kernel, architecture)
and also to trace the cpu hotplug activity with other power events. I
have tested these traces events on an arm platform.
Subject: [PATCH 1/2] cpu hotplug tracepoint
this patch adds new events for cpu hotplug tracing
* plug/unplug sequence
* core and architecture latency measurements
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
---
include/trace/events/cpu_hotplug.h | 103 ++++++++++++++++++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 include/trace/events/cpu_hotplug.h
diff --git a/include/trace/events/cpu_hotplug.h
b/include/trace/events/cpu_hotplug.h
new file mode 100644
index 0000000..af05775
--- /dev/null
+++ b/include/trace/events/cpu_hotplug.h
@@ -0,0 +1,103 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM cpu_hotplug
+
+#if !defined(_TRACE_CPU_HOTPLUG_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_CPU_HOTPLUG_H
+
+#include <linux/tracepoint.h>
+
+DECLARE_EVENT_CLASS(cpu_hotplug,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid),
+
+ TP_STRUCT__entry(
+ __field( unsigned int, cpuid )
+ ),
+
+ TP_fast_assign(
+ __entry->cpuid = cpuid;
+ ),
+
+ TP_printk("cpuid=%u", __entry->cpuid)
+);
+
+/* Core function of cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_down_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+/* Architecture function for cpu hotplug */
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_disable_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_disable_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_die_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_die_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_start,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+DEFINE_EVENT(cpu_hotplug, cpu_hotplug_arch_up_end,
+
+ TP_PROTO(unsigned int cpuid),
+
+ TP_ARGS(cpuid)
+);
+
+#endif /* _TRACE_CPU_HOTPLUG_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox