[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Oct 2013 19:35:53 +0200
From: Ingo Molnar <mingo@...nel.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>, Mel Gorman <mgorman@...e.de>,
Rik van Riel <riel@...hat.com>,
Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Johannes Weiner <hannes@...xchg.org>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] Optimize the cpu hotplug locking -v2
* Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> On Thu, Oct 10, 2013 at 06:50:46PM +0200, Ingo Molnar wrote:
> >
> > * Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > > On Thu, Oct 10, 2013 at 04:57:38PM +0200, Ingo Molnar wrote:
> > >
> > > > So ... why not make it _really_ cheap, i.e. the read lock costing
> > > > nothing, and tie CPU hotplug to freezing all tasks in the system?
> > >
> > > Such that we freeze regular tasks in userspace and kernel tasks in
> > > their special freezer callback so as to guarantee minimal state?
> >
> > Yes, absolutely.
>
> That does add quite a bit of latency to the hotplug operations, which
> IIRC slows down things like boot, suspend, and resume.
I think it should _speed up_ suspend: instead of bringing down each CPU
one by one, they could just be all stopped.
Same for bootup - it's not really a hotplug operation in the traditional
sense, as all CPUs are 'present' at once, and they could be added in one
group operation instead of serializing the bootup.
Also, most CPU bootup sequences are serialized.
It would slow down individual CPU hotplug/hotunplug - and that is what is
a really rare operation outside broken schemes to save power ...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists