* Re: [PATCH 1/1] Remap Acer WMI touchpad toggle key to F21 used by X
From: Martin Pitt @ 2011-03-01 11:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1298978205-31767-1-git-send-email-jlee@novell.com>
Hello Lee,
Lee, Chun-Yi [2011-03-01 19:16 +0800]:
> Currently, Acer WMI driver generates KEY_F22 but this
> will soon change to KEY_TOUCHPAD_TOOGLE.
>
> X has defined F21 for the purpose of touchpad toggle and other
> udev keymaps align with this meaning. Patch aligns Acer WMI
> hotkey drivers with F21.
Right, that's what we've agreed on between X.org and udev.
Applied, thanks!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [PATCH 1/1] Remap Acer WMI touchpad toggle key to F21 used by X
From: Lee, Chun-Yi @ 2011-03-01 11:16 UTC (permalink / raw)
To: linux-hotplug
Currently, Acer WMI driver generates KEY_F22 but this
will soon change to KEY_TOUCHPAD_TOOGLE.
X has defined F21 for the purpose of touchpad toggle and other
udev keymaps align with this meaning. Patch aligns Acer WMI
hotkey drivers with F21.
Tested on Acer TravelMate 8572 notebook using acer-wmi driver.
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Lee, Chun-Yi <jlee@novell.com>
---
| 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index dd511d5..7f849d3 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -46,6 +46,7 @@ ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Asus Extra Buttons",
ENV{DMI_VENDOR}="Sony*", KERNELS="input*", ATTRS{name}="Sony Vaio Keys", RUN+="keymap $name module-sony"
ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC WMI hotkeys", RUN+="keymap $name 0x6B f21"
ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC Hotkey Driver", RUN+="keymap $name 0x37 f21"
+ENV{DMI_VENDOR}="Acer*", KERNELS="input*", ATTRS{name}="Acer WMI hotkeys", RUN+="keymap $name 0x82 f21"
# Older Vaios have some different keys
ENV{DMI_VENDOR}="Sony*", ATTR{[dmi/id]product_name}="*PCG-C1*|*PCG-K25*|*PCG-F1*|*PCG-F2*|*PCG-F3*|*PCG-F4*|*PCG-F5*|*PCG-F6*|*PCG-FX*|*PCG-FRV*|*PCG-GR*|*PCG-TR*|*PCG-NV*|*PCG-Z*|*VGN-S360*", ATTRS{name}="Sony Vaio Keys", RUN+="keymap $name module-sony-old"
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Vincent Guittot @ 2011-02-28 13:36 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-kernel, linux-hotplug, Frederic Weisbecker, Steven Rostedt,
amit.kucheria, Rusty Russell, Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1102241900540.2701@localhost6.localdomain6>
On 24 February 2011 19:40, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 24 Feb 2011, Vincent Guittot wrote:
>
> Please send full patch series not a single V5 2/2 which lacks any
> references to 0/2 1/2.
>
I'm going to create a complete patch series and add a 0/2 reference
with more details about the patch purpose.
This patch adds traces for 2 main goals. The 1st one is to detect the
plug and unplug of a core. As explained by Nicolas, smp arm platforms
use the cpu hotplug feature. In fact, the state of a core can modify
the cpuidle activity because some Arm SoC can't go into deep idle
state when more than one core is plugged and also because running into
mono core mode makes the cpuidle job easier and more efficient which
results in the improvement of powersaving of some use cases. That's
why it's interesting to monitor the plug state of cores and to
correlate it with cpuidle traces. The goal is not to make cpu hotplug
feature part of cpuidle one but to use cpu hotplug in a low frequency
manner (few dozens of seconds or minutes), we plug several cpus only
when needed by the system activity.
Then, the 2nd goal of these traces is to measure the duration of cpu
plug/unplug sequence across various use cases and cpu load. Cpu
hotplug is known to be an expensive operation which also takes a
variable time depending of other processes' activity (from hundreds of
ms up to few seconds). I have seen with these traces that the arch
part stays almost constant whatever the cpu load is on arm platform,
and I have also seen that the core duration depends of threads
creation when we plug a cpu.
>> Please find below a new proposal for adding trace events for cpu hotplug:
>
> Either it's a patch or a proposal. Darn, why think people that
> proposal is such a important word? It's just useless. You don't have
> to sell anything to your manager. You provide a patch which is judged
> on it's technical merits and correctness. Nothing else.
>
>> -the lock/unlock of cpu_add_remove_lock mutex is now outside the trace
>>
>> 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.
>
> This belongs into a cover mail [0/2] not into the patch itself
>
>> Subject: [PATCH 2/2] add hotplug tracepoint
>
> While your mail subject is correct, this is not.
>
> If you would have sent a [0/2] cover mail with all the above blurb in
> it then this extra subject line would be not needed at all.
>
>> this patch adds new events for cpu hotplug tracing
>
> Sentences start with an upper case letter.
>
> Also we already know that this is a patch. Where is the value of this
> changelog? It does not tell more than the subject line.
>
>> * plug/unplug sequence
>
> How surprising.
>
>> * core and architecture latency measurements
>
> No it does not. It does not add latency measurements. It merily adds
> tracepoints which allow you to compute the time spent in the various
> steps of the hotplug state machine and the overall time.
>
>> #ifdef CONFIG_SMP
>> /* Serializes the updates to cpu_online_mask, cpu_present_mask */
>> static DEFINE_MUTEX(cpu_add_remove_lock);
>> @@ -197,10 +200,13 @@ struct take_cpu_down_param {
>> static int __ref take_cpu_down(void *_param)
>> {
>> struct take_cpu_down_param *param = _param;
>> + unsigned int cpu = (unsigned int)(param->hcpu);
>> int err;
>>
>> /* Ensure this CPU doesn't handle any more interrupts. */
>> + trace_cpu_hotplug_disable_start(cpu);
>> err = __cpu_disable();
>> + trace_cpu_hotplug_disable_end(cpu);
>
> How useful. What about recording the return code of __cpu_disable()?
>
The goal is to monitor the cpu hotplug activity and duration. I want
to detect 2 kind of cpu_down/cpu_up call, ones which succeed to
unplug/plug a core and ones which don't. But I'm not sure that we need
to sort the failed calls into to the trace. We trace them because too
much fails could point out a bug or a wrong use of cpu hotplug.
>> if (err < 0)
>> return err;
>
>> + trace_cpu_hotplug_down_start(cpu);
>> +
>
> What's the point of this tracepoint _BEFORE_ the cpu_hotplug_disabled
> check without recording cpu_hotplug_disabled ?
>
I want to trace all cpu_down call even those which returns immediately
which will be part of the failed calls.
>> if (cpu_hotplug_disabled) {
>> err = -EBUSY;
>> goto out;
>> @@ -284,6 +294,8 @@ int __ref cpu_down(unsigned int cpu)
>> err = _cpu_down(cpu, 0);
>>
>> out:
>> + trace_cpu_hotplug_down_end(cpu);
>
> And this one is misplaced as well. It wants to be only called when we
> actually called _cpu_down() and it wants to record the return code as
> well.
>
It has been placed here to be called each time
trace_cpu_hotplug_down_start is called.
>> +
>> cpu_maps_update_done();
>> return err;
>> }
>> @@ -310,7 +322,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);
>
> See above.
>
>> if (ret != 0)
>> goto out_notify;
>> BUG_ON(!cpu_online(cpu));
>> @@ -369,6 +383,8 @@ int __cpuinit cpu_up(unsigned int cpu)
>>
>> cpu_maps_update_begin();
>>
>> + trace_cpu_hotplug_up_start(cpu);
>> +
>
> Ditto
>
>> if (cpu_hotplug_disabled) {
>> err = -EBUSY;
>> goto out;
>> @@ -377,6 +393,8 @@ int __cpuinit cpu_up(unsigned int cpu)
>> err = _cpu_up(cpu, 0);
>>
>> out:
>> + trace_cpu_hotplug_up_end(cpu);
>> +
>
> Sigh.
>
>> cpu_maps_update_done();
>> return err;
>
> Thanks,
>
> tglx
>
Thanks,
Vincent
^ permalink raw reply
* Re: [gentoo-user] automounting usb drives
From: Stéphane Guedon @ 2011-02-27 16:58 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: Text/Plain, Size: 1200 bytes --]
On Sunday 27 February 2011 13:39:49 Stéphane Guedon wrote:
> On Sunday 27 February 2011 12:13:21 luis jure wrote:
> > on 2011-02-27 at 10:20 Duong "Yang" Ha Nguyen wrote:
> > >Hal is deprecated. Try avoiding it as much as possible.
> >
> > that's what i'm doing, for sure!
>
> I have read all the discussion, and, unfortunately, I can't help you Luis.
> But I am asking the way to assign mountpoint like hal did.
>
> As it is said, Hal is deprecated. But it was easy to say "when you plug
> 6566-3243 flash drive, the mountpoint should be my_usbdisk".
>
> Now, automounting works good and great for me with udev/udisks, no problem,
> except that I would like to have the same behavior : having my drives to
> the mount point I want (having good icons rather than just a usual folder
> icon would be a plus !).
>
> I am right now on KDE 4.6, and so...
solved using mlabel...
I needed to look upon ubuntu doc ! This is a little bit crap !
but thanks ! :-)
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: udev fixing mount point
From: Stéphane Guedon @ 2011-02-26 18:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201102261736.59953.stephane@22decembre.eu>
[-- Attachment #1: Type: Text/Plain, Size: 1151 bytes --]
On Saturday 26 February 2011 19:53:52 you wrote:
> Hi,
>
> On Sat, Feb 26, 2011 at 11:36 AM, Stéphane Guedon
>
> <stephane@22decembre.eu> wrote:
> > Presently, I have only udev and udisks on that part of the process. Hal
> > isn't running anymore, but automounting still works.
>
> If there's an /etc/fstab entry for your device, udisks will use that
> instead of creating a directory itself (udisks simply calls mount(8)
> as the user). You probably want to use one of the 'user' or 'users'
> option to allow the unprivileged desktop session to mount the device,
> otherwise it won't work. For example
>
> /dev/disk/by-uuid/6566-3267 /media/NeoParker auto defaults,users 0 0
>
> should work (you of course need to mkdir that directory yourself).
>
> David
So, this means each media to be plugged regulary should have its mountpoint
setup before...
And the others are automatic.
Ok...
Thank you !
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: udev fixing mount point
From: David Zeuthen @ 2011-02-26 18:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201102261736.59953.stephane@22decembre.eu>
Hi,
On Sat, Feb 26, 2011 at 11:36 AM, Stéphane Guedon
<stephane@22decembre.eu> wrote:
> Presently, I have only udev and udisks on that part of the process. Hal isn't
> running anymore, but automounting still works.
If there's an /etc/fstab entry for your device, udisks will use that
instead of creating a directory itself (udisks simply calls mount(8)
as the user). You probably want to use one of the 'user' or 'users'
option to allow the unprivileged desktop session to mount the device,
otherwise it won't work. For example
/dev/disk/by-uuid/6566-3267 /media/NeoParker auto defaults,users 0 0
should work (you of course need to mkdir that directory yourself).
David
^ permalink raw reply
* udev fixing mount point
From: Stéphane Guedon @ 2011-02-26 16:36 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]
Hello
I write to you because I don't find any solution or any manuals.
I would like to fix the mount point of several usb devices. This is a classic
queries, many people around the world using Linux have the same aim.
Presently, I have only udev and udisks on that part of the process. Hal isn't
running anymore, but automounting still works.
I have read many udev rules over the internet, and I have writen at least two
that work...
But after working, unmounting in Kde isn't working anymore, whereas the basic
settings (plugging usb, let kde/udev/system/whatever mount, work on doc, then
unmount with the appropriate button in kde...) work good, but the mount point
is ugly and unremindable.
The only thing I want is replace the mount point (aka '/media/6566-3267') by
the one I want ( '/media/NeoParker' or '/media/htc' for an other one).
So, is there a rule to put like :
ENV{ID_FS_UUID}=="6566-3267", ENV{MOUNTPOINT}="NeoParker" ?
And it's all, all the rest of the process get its life (creating mount point,
mount, ... , unmount, rmdir of the mountpoint) and I haven't any thing to say
on it.
The fact is that just a simple rule like the one I have just said would be so
easy for every user ... But I don't find any, so, I ask you.
Sorry if I disturb you.
Thank you for your help.
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: [PATCH] udev-watch: try inotify_init if inotify_init1 is not available
From: Kay Sievers @ 2011-02-25 17:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1298649324-12077-1-git-send-email-sledz@dresearch.de>
On Fri, Feb 25, 2011 at 18:01, Steffen Sledz <sledz@dresearch.de> wrote:
> Am 25.02.2011 17:57, schrieb Kay Sievers:
>> On Fri, Feb 25, 2011 at 16:55, Steffen Sledz <sledz@dresearch.de> wrote:
>>> inotify_init1 first appeared in Linux 2.6.27
>>
>> We depend on that or a more recent kernel for a few other reasons too.
>> .27 might be the first on where this udev version compiles, but all
>> below .32 is pretty much untested and known to fail during runtime in
>> some areas. Let's not fix such compile failures, it is unlikely that
>> udev will run properly for other reasons than inotify.
>
> Hmmm?
>
> Is there an overview of these reasons? We like/need to use udev-151 (or newer) together with linux 2.6.24.
Not really. It's all a moving target in one direction only. We only
really support compatibility for newer kernels with old userspace. Old
kernels with new userspace are usually not even tested.
Support for kernels with the deprecated sysfs layout
(CONFIG_SYSFS_DEPRECATED) has been removed a while ago.
Some lookup/enumeration features in libudev relies on information in
/sys only available in kernels >= .31.
Some stuff relies on DEVNAME set by the kernel, which was part of the
devtmpfs changes. Udev should run fine on plain tmpfs, but it is also
not tested anymore. Also races that happen only with tmpfs don't get
fixed anymore.
Some changes are visible in the compat rules files:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/misc/30-kernel-compat.rules;hb=HEAD
The same rules applie here, we already dropped stuff here for kernels
older than .27.
Kay
^ permalink raw reply
* Re: [PATCH] udev-watch: try inotify_init if inotify_init1 is not
From: Steffen Sledz @ 2011-02-25 17:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1298649324-12077-1-git-send-email-sledz@dresearch.de>
Am 25.02.2011 17:57, schrieb Kay Sievers:
> On Fri, Feb 25, 2011 at 16:55, Steffen Sledz <sledz@dresearch.de> wrote:
>> inotify_init1 first appeared in Linux 2.6.27
>
> We depend on that or a more recent kernel for a few other reasons too.
> .27 might be the first on where this udev version compiles, but all
> below .32 is pretty much untested and known to fail during runtime in
> some areas. Let's not fix such compile failures, it is unlikely that
> udev will run properly for other reasons than inotify.
Hmmm?
Is there an overview of these reasons? We like/need to use udev-151 (or newer) together with linux 2.6.24.
Steffen
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@DResearch.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
^ permalink raw reply
* Re: [PATCH] udev-watch: try inotify_init if inotify_init1 is not available
From: Kay Sievers @ 2011-02-25 16:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1298649324-12077-1-git-send-email-sledz@dresearch.de>
On Fri, Feb 25, 2011 at 16:55, Steffen Sledz <sledz@dresearch.de> wrote:
> inotify_init1 first appeared in Linux 2.6.27
We depend on that or a more recent kernel for a few other reasons too.
.27 might be the first on where this udev version compiles, but all
below .32 is pretty much untested and known to fail during runtime in
some areas. Let's not fix such compile failures, it is unlikely that
udev will run properly for other reasons than inotify.
Thanks,
Kay
^ permalink raw reply
* [PATCH] udev-watch: try inotify_init if inotify_init1 is not available
From: Steffen Sledz @ 2011-02-25 15:55 UTC (permalink / raw)
To: linux-hotplug
inotify_init1 first appeared in Linux 2.6.27
Signed-off-by: Steffen Sledz <sledz@dresearch.de>
---
udev/udev-watch.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/udev/udev-watch.c b/udev/udev-watch.c
index f51a10d..ac679ec 100644
--- a/udev/udev-watch.c
+++ b/udev/udev-watch.c
@@ -39,6 +39,8 @@ static int inotify_fd = -1;
int udev_watch_init(struct udev *udev)
{
inotify_fd = inotify_init1(IN_CLOEXEC);
+ if (inotify_fd = -1 && errno = ENOSYS)
+ inotify_fd = inotify_init();
if (inotify_fd < 0)
err(udev, "inotify_init failed: %m\n");
return inotify_fd;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Thomas Gleixner @ 2011-02-24 21:33 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Alan Cox, Nicolas Pitre, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar
In-Reply-To: <1298582255.5226.843.camel@laptop>
On Thu, 24 Feb 2011, Peter Zijlstra wrote:
> On Thu, 2011-02-24 at 22:12 +0100, Thomas Gleixner wrote:
>
> > If you take down the whole SoC, then it's full S2RAM or some
> > equivilant thing. That's a different story and propably requires the
> > whole hotplug muck.
>
> Didn't we, during the whole wakelock trainwreck, that s2ram could be
> done from idle as well (for hardware where the whole opportunistic
> suspend was sensible to begin with)?
Yes, needs some more changes to the whole infrastructure of clocks and
power gates, but it's doable.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Peter Zijlstra @ 2011-02-24 21:17 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Alan Cox, Nicolas Pitre, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1102242206560.2701@localhost6.localdomain6>
On Thu, 2011-02-24 at 22:12 +0100, Thomas Gleixner wrote:
> If you take down the whole SoC, then it's full S2RAM or some
> equivilant thing. That's a different story and propably requires the
> whole hotplug muck.
Didn't we, during the whole wakelock trainwreck, that s2ram could be
done from idle as well (for hardware where the whole opportunistic
suspend was sensible to begin with)?
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Thomas Gleixner @ 2011-02-24 21:12 UTC (permalink / raw)
To: Alan Cox
Cc: Nicolas Pitre, Peter Zijlstra, Vincent Guittot, lkml,
linux-hotplug, Frederic Weisbecker, Steven Rostedt, amit.kucheria,
Rusty Russell, Ingo Molnar
In-Reply-To: <20110224210431.7a6bba68@lxorguk.ukuu.org.uk>
On Thu, 24 Feb 2011, Alan Cox wrote:
> > That's the equivalent of physical hotplug, but we still have all the
> > memory state around, so it is possible from idle, when we have the
>
> All sorts of other state goes walking as well though - on die device
> state for example like the GPU context may well also evaporate or
> disappear except for the minimum needed for scanout.
>
> It's not just about the CPU its a system (albeit a SoC in most cases)
> going to sleep lock stock and barrel except for IRQ notifications, and in
> some cases things like offloaded audio playback.
I guess we are talking about different things.
If you take down one core of a package then it does not take down the
whole SoC and does not take down devices either. Device take down is
or should be handled by explicit clock and power gating.
If you take down the whole SoC, then it's full S2RAM or some
equivilant thing. That's a different story and propably requires the
whole hotplug muck.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Paul E. McKenney @ 2011-02-24 21:11 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Thomas Gleixner, Nicolas Pitre, Alan Cox, Vincent Guittot, lkml,
linux-hotplug, Frederic Weisbecker, Steven Rostedt, amit.kucheria,
Rusty Russell, Ingo Molnar
In-Reply-To: <1298581112.5226.838.camel@laptop>
On Thu, Feb 24, 2011 at 09:58:32PM +0100, Peter Zijlstra wrote:
> On Thu, 2011-02-24 at 21:47 +0100, Thomas Gleixner wrote:
> > On Thu, 24 Feb 2011, Peter Zijlstra wrote:
> >
> > > On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
> > >
> > > > Most SMP ARM processors are going to use it soon. Powering down idle
> > > > cores provides substantial power saving.
> > >
> > > And why can't regular idle paths be used? CPU hotplug is a massively
> > > expensive operation.
> >
> > To achieve the same result from idle, you need to exclude the core
> > from any unwanted wakeup. At the moment cpu unplug is the only way to
> > achieve that.
>
> Right, everything is a nail because all we have is a hammer like.
>
> > If you want to do the same from idle, then we need the isolation
> > features Frederic is working on for RT/HPC.
> >
> > They allow us to isolate cores completely for totaly different
> > reasons, but it could be resused to provide full isolation of a core
> > in a very deep power state.
>
> Exactly.
>
> > That would solve the problem w/o going through kstompmachine
>
> Right, kstopmachine is a large part of the problem, but cpu hotplug
> really does an insane amount of work if all you want is to idle the
> core.
You do indeed need to know that the CPU will be powered off for quite
some time to be worth the extra work. And a number of embedded devices
do have this level of foreknowledge -- for example, they might use the
second CPU only when the user is doing some computationally intensive
task, so that the device would normally be using only a single CPU.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Alan Cox @ 2011-02-24 21:04 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Nicolas Pitre, Peter Zijlstra, Vincent Guittot, lkml,
linux-hotplug, Frederic Weisbecker, Steven Rostedt, amit.kucheria,
Rusty Russell, Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1102242148400.2701@localhost6.localdomain6>
> That's the equivalent of physical hotplug, but we still have all the
> memory state around, so it is possible from idle, when we have the
All sorts of other state goes walking as well though - on die device
state for example like the GPU context may well also evaporate or
disappear except for the minimum needed for scanout.
It's not just about the CPU its a system (albeit a SoC in most cases)
going to sleep lock stock and barrel except for IRQ notifications, and in
some cases things like offloaded audio playback.
Alan
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Thomas Gleixner @ 2011-02-24 21:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nicolas Pitre, Alan Cox, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar, Paul E. McKenney
In-Reply-To: <1298581112.5226.838.camel@laptop>
On Thu, 24 Feb 2011, Peter Zijlstra wrote:
> On Thu, 2011-02-24 at 21:47 +0100, Thomas Gleixner wrote:
> > On Thu, 24 Feb 2011, Peter Zijlstra wrote:
> >
> > > On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
> > >
> > > > Most SMP ARM processors are going to use it soon. Powering down idle
> > > > cores provides substantial power saving.
> > >
> > > And why can't regular idle paths be used? CPU hotplug is a massively
> > > expensive operation.
> >
> > To achieve the same result from idle, you need to exclude the core
> > from any unwanted wakeup. At the moment cpu unplug is the only way to
> > achieve that.
>
> Right, everything is a nail because all we have is a hammer like.
>
> > If you want to do the same from idle, then we need the isolation
> > features Frederic is working on for RT/HPC.
> >
> > They allow us to isolate cores completely for totaly different
> > reasons, but it could be resused to provide full isolation of a core
> > in a very deep power state.
>
> Exactly.
>
> > That would solve the problem w/o going through kstompmachine
>
> Right, kstopmachine is a large part of the problem, but cpu hotplug
> really does an insane amount of work if all you want is to idle the
> core.
As far as I can tell the isolation stuff covers lot's of the problems
including RCU, but there is still a way to go. And the good new is
that, when a cpu is idle it has not much state to preserve if its
properly isolated and the memory is not going away.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Peter Zijlstra @ 2011-02-24 20:58 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Nicolas Pitre, Alan Cox, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar, Paul E. McKenney
In-Reply-To: <alpine.LFD.2.00.1102242130360.2701@localhost6.localdomain6>
On Thu, 2011-02-24 at 21:47 +0100, Thomas Gleixner wrote:
> On Thu, 24 Feb 2011, Peter Zijlstra wrote:
>
> > On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
> >
> > > Most SMP ARM processors are going to use it soon. Powering down idle
> > > cores provides substantial power saving.
> >
> > And why can't regular idle paths be used? CPU hotplug is a massively
> > expensive operation.
>
> To achieve the same result from idle, you need to exclude the core
> from any unwanted wakeup. At the moment cpu unplug is the only way to
> achieve that.
Right, everything is a nail because all we have is a hammer like.
> If you want to do the same from idle, then we need the isolation
> features Frederic is working on for RT/HPC.
>
> They allow us to isolate cores completely for totaly different
> reasons, but it could be resused to provide full isolation of a core
> in a very deep power state.
Exactly.
> That would solve the problem w/o going through kstompmachine
Right, kstopmachine is a large part of the problem, but cpu hotplug
really does an insane amount of work if all you want is to idle the
core.
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Thomas Gleixner @ 2011-02-24 20:49 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Peter Zijlstra, Alan Cox, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1102241536120.31831@xanadu.home>
On Thu, 24 Feb 2011, Nicolas Pitre wrote:
> On Thu, 24 Feb 2011, Peter Zijlstra wrote:
>
> > On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
> >
> > > Most SMP ARM processors are going to use it soon. Powering down idle
> > > cores provides substantial power saving.
> >
> > And why can't regular idle paths be used? CPU hotplug is a massively
> > expensive operation.
>
> The idle path assumes that the CPU state is preserved. We're talking
> about cores completely going down with power pulled beneath them and
> eventually rebooted dynamically here.
That's the equivalent of physical hotplug, but we still have all the
memory state around, so it is possible from idle, when we have the
full isolation features in place.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Peter Zijlstra @ 2011-02-24 20:49 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Thomas Gleixner, Alan Cox, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1102241536120.31831@xanadu.home>
On Thu, 2011-02-24 at 15:40 -0500, Nicolas Pitre wrote:
> On Thu, 24 Feb 2011, Peter Zijlstra wrote:
>
> > On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
> >
> > > Most SMP ARM processors are going to use it soon. Powering down idle
> > > cores provides substantial power saving.
> >
> > And why can't regular idle paths be used? CPU hotplug is a massively
> > expensive operation.
>
> The idle path assumes that the CPU state is preserved.
Not much of it,
> We're talking
> about cores completely going down with power pulled beneath them and
> eventually rebooted dynamically here.
I think you can get away with actually pulling the power and re-initing
the cpu to idle from the idle path and the rest of the kernel not
caring.
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Thomas Gleixner @ 2011-02-24 20:47 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nicolas Pitre, Alan Cox, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar, Paul E. McKenney
In-Reply-To: <1298579452.5226.834.camel@laptop>
On Thu, 24 Feb 2011, Peter Zijlstra wrote:
> On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
>
> > Most SMP ARM processors are going to use it soon. Powering down idle
> > cores provides substantial power saving.
>
> And why can't regular idle paths be used? CPU hotplug is a massively
> expensive operation.
To achieve the same result from idle, you need to exclude the core
from any unwanted wakeup. At the moment cpu unplug is the only way to
achieve that.
If you want to do the same from idle, then we need the isolation
features Frederic is working on for RT/HPC.
They allow us to isolate cores completely for totaly different
reasons, but it could be resused to provide full isolation of a core
in a very deep power state.
That would solve the problem w/o going through kstompmachine
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Nicolas Pitre @ 2011-02-24 20:40 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Thomas Gleixner, Alan Cox, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar
In-Reply-To: <1298579452.5226.834.camel@laptop>
On Thu, 24 Feb 2011, Peter Zijlstra wrote:
> On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
>
> > Most SMP ARM processors are going to use it soon. Powering down idle
> > cores provides substantial power saving.
>
> And why can't regular idle paths be used? CPU hotplug is a massively
> expensive operation.
The idle path assumes that the CPU state is preserved. We're talking
about cores completely going down with power pulled beneath them and
eventually rebooted dynamically here.
Nicolas
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Alan Cox @ 2011-02-24 20:40 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Nicolas Pitre, Thomas Gleixner, Vincent Guittot, lkml,
linux-hotplug, Frederic Weisbecker, Steven Rostedt, amit.kucheria,
Rusty Russell, Ingo Molnar
In-Reply-To: <1298579452.5226.834.camel@laptop>
On Thu, 24 Feb 2011 21:30:52 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
>
> > Most SMP ARM processors are going to use it soon. Powering down idle
> > cores provides substantial power saving.
And some X86 will be doing likewise
> And why can't regular idle paths be used? CPU hotplug is a massively
> expensive operation.
They are not CPU idling on our idle path, they are dropping into suspend
to RAM, that means they need to drop the devices into S2R states as well.
And yes the paths are currently expensive in places but they need to be
sped up more not messed up. For most devices it's not going to be that
hard to sort out - the big ugly is x86 patching the instruction stream
back and forth each suspend/resume which is in "durrr..." category of
smartness.
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Peter Zijlstra @ 2011-02-24 20:30 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Thomas Gleixner, Alan Cox, Vincent Guittot, lkml, linux-hotplug,
Frederic Weisbecker, Steven Rostedt, amit.kucheria, Rusty Russell,
Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1102241522130.31831@xanadu.home>
On Thu, 2011-02-24 at 15:24 -0500, Nicolas Pitre wrote:
> Most SMP ARM processors are going to use it soon. Powering down idle
> cores provides substantial power saving.
And why can't regular idle paths be used? CPU hotplug is a massively
expensive operation.
^ permalink raw reply
* Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events
From: Peter Zijlstra @ 2011-02-24 20:27 UTC (permalink / raw)
To: Alan Cox
Cc: Vincent Guittot, linux-kernel, linux-hotplug, Frederic Weisbecker,
Steven Rostedt, amit.kucheria, Rusty Russell, Ingo Molnar,
Thomas Gleixner
In-Reply-To: <20110224201124.138311ba@lxorguk.ukuu.org.uk>
On Thu, 2011-02-24 at 20:11 +0000, Alan Cox wrote:
> > Anybody who is interested in the latency of cpu hotplug is deluding
> > himself, also cpu hotplug is _NOT_ a power management feature, so the
> > rest of your justification just disappeared as well.
>
> Actually CPU hotplug is a power management feature on some devices where
> you need to shutdown one of the cores to enter low power modes.
Aren't we confusing things here? Surely simply idling a core is good
enough? Why would we want to go through the whole CPU hotplug dance
simply to enter a low power state?
> Remember we use it as part of the suspend paths and various processors
> nowdays drop into a suspend to RAM type state on CPU idling.
Which would illustrate the above point. CPU hotplug is a terribly
expensive op, and doing so from idle is really utterly ridiculous (nor
can we, idle is not supposed to schedule and cpu-hotplug needs to
schedule)
Why can't we do these things from the normal idle path, presumably these
state transitions are 'fast', so we can implement them as normal idle
modes.
The scheduler has (due to power7 support) the ability to favour lower
cpu nrs when placing tasks, so idle !bsp (assuming cpu0 is the bsp) can
drop into their special state, and then when the bsp goes idle it can do
whatever it needs to do.
All that needs is to make sure smp_send_reschedule() can wake !bsp cores
from their special sleep state, but that's all arch code anyway.
I really see no reason to conflate cpu-hotplug and idle/power-states.
^ permalink raw reply
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