On Thu, Jan 31, 2013 at 12:11:11PM -, Thomas Gleixner wrote:
> The current CPU hotplug implementation has become an increasing
> nightmare full of races and undocumented behaviour. The main issue of
> the current hotplug scheme is the completely asymetric
> startup/teardown process. The
On Thu, Jan 31, 2013 at 12:11:11PM -, Thomas Gleixner wrote:
The current CPU hotplug implementation has become an increasing
nightmare full of races and undocumented behaviour. The main issue of
the current hotplug scheme is the completely asymetric
startup/teardown process. The hotplug
Thomas Gleixner writes:
> On Fri, 1 Feb 2013, Linus Torvalds wrote:
>> So for me it's the "expose these states" that I get worried about.. A
>> random driver should not necessarily even be able to *see* this, and
>> decide to be clever and take advantage of the ordering.
>>
>> So I'd hope there
Thomas Gleixner t...@linutronix.de writes:
On Fri, 1 Feb 2013, Linus Torvalds wrote:
So for me it's the expose these states that I get worried about.. A
random driver should not necessarily even be able to *see* this, and
decide to be clever and take advantage of the ordering.
So I'd hope
On Fri, 1 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner wrote:
> >
> > Just face it. The current hotplug maze has 100+ states which are
> > completely undocumented. They are asymetric vs. startup and
> > teardown. They just exists and work somehow aside of the
On Fri, 1 Feb 2013, Linus Torvalds wrote:
On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner t...@linutronix.de wrote:
Just face it. The current hotplug maze has 100+ states which are
completely undocumented. They are asymetric vs. startup and
teardown. They just exists and work somehow
On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner wrote:
>
> Just face it. The current hotplug maze has 100+ states which are
> completely undocumented. They are asymetric vs. startup and
> teardown. They just exists and work somehow aside of the occasional
> hard to decode hickup.
>
> Do you
On Fri, 1 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 1, 2013 at 8:48 AM, Thomas Gleixner wrote:
> I think we want as many people as possible cc'd on this. You may think
> it's an obvious improvement, but maybe it's just because you now
> understand the code because you wrote it yourself, not
On Fri, Feb 1, 2013 at 8:48 AM, Thomas Gleixner wrote:
>> Methinks Tejun needed a cc on this lot ;)
>
> Not really.
I think we want as many people as possible cc'd on this. You may think
it's an obvious improvement, but maybe it's just because you now
understand the code because you wrote it
On Thu, 31 Jan 2013, Andrew Morton wrote:
> On Thu, 31 Jan 2013 15:44:10 -
> Thomas Gleixner wrote:
>
> > At the end hotplug should run through an array of callbacks on both
> > sides with explicit core synchronization points. The ordering should
> > look like this:
> >
> > CPUHP_OFFLINE
On Thu, 31 Jan 2013 15:44:10 -
Thomas Gleixner wrote:
> At the end hotplug should run through an array of callbacks on both
> sides with explicit core synchronization points. The ordering should
> look like this:
>
> CPUHP_OFFLINE // Start state.
> CPUHP_PREP_ //
The current CPU hotplug implementation has become an increasing
nightmare full of races and undocumented behaviour. The main issue of
the current hotplug scheme is the completely asymetric
startup/teardown process. The hotplug notifiers are mostly
undocumented and the CPU_* actions in lots of
The current CPU hotplug implementation has become an increasing
nightmare full of races and undocumented behaviour. The main issue of
the current hotplug scheme is the completely asymetric
startup/teardown process. The hotplug notifiers are mostly
undocumented and the CPU_* actions in lots of
On Thu, 31 Jan 2013 15:44:10 -
Thomas Gleixner t...@linutronix.de wrote:
At the end hotplug should run through an array of callbacks on both
sides with explicit core synchronization points. The ordering should
look like this:
CPUHP_OFFLINE // Start state.
On Thu, 31 Jan 2013, Andrew Morton wrote:
On Thu, 31 Jan 2013 15:44:10 -
Thomas Gleixner t...@linutronix.de wrote:
At the end hotplug should run through an array of callbacks on both
sides with explicit core synchronization points. The ordering should
look like this:
On Fri, Feb 1, 2013 at 8:48 AM, Thomas Gleixner t...@linutronix.de wrote:
Methinks Tejun needed a cc on this lot ;)
Not really.
I think we want as many people as possible cc'd on this. You may think
it's an obvious improvement, but maybe it's just because you now
understand the code because
On Fri, 1 Feb 2013, Linus Torvalds wrote:
On Fri, Feb 1, 2013 at 8:48 AM, Thomas Gleixner t...@linutronix.de wrote:
I think we want as many people as possible cc'd on this. You may think
it's an obvious improvement, but maybe it's just because you now
understand the code because you wrote it
On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner t...@linutronix.de wrote:
Just face it. The current hotplug maze has 100+ states which are
completely undocumented. They are asymetric vs. startup and
teardown. They just exists and work somehow aside of the occasional
hard to decode hickup.
18 matches
Mail list logo
