* Preeti U Murthy wrote:
> On 03/02/2015 08:26 PM, Peter Zijlstra wrote:
> > On Fri, Feb 27, 2015 at 02:19:05PM +0530, Preeti U Murthy wrote:
> >> The problem reported in the changelog of this patch is causing severe
> >> regressions very frequently on our machines for certain usecases. It would
Ping.
On 03/16/2015 10:22 AM, Preeti U Murthy wrote:
> Hi Peter, Ingo, Thomas,
>
> Can you please take a look at the conversation on this thread ?
> This fix is urgent.
>
> Regards
> Preeti U Murthy
>
> On 03/02/2015 08:26 PM, Peter Zijlstra wrote:
>> On Fri, Feb 27, 2015 at 02:19:05PM +0530, P
Hi Peter, Ingo, Thomas,
Can you please take a look at the conversation on this thread ?
This fix is urgent.
Regards
Preeti U Murthy
On 03/02/2015 08:26 PM, Peter Zijlstra wrote:
> On Fri, Feb 27, 2015 at 02:19:05PM +0530, Preeti U Murthy wrote:
>> The problem reported in the changelog of this pa
On 03/02/2015 08:26 PM, Peter Zijlstra wrote:
> On Fri, Feb 27, 2015 at 02:19:05PM +0530, Preeti U Murthy wrote:
>> The problem reported in the changelog of this patch is causing severe
>> regressions very frequently on our machines for certain usecases. It would
>> help to put in a fix in place fi
On Fri, Feb 27, 2015 at 02:19:05PM +0530, Preeti U Murthy wrote:
> The problem reported in the changelog of this patch is causing severe
> regressions very frequently on our machines for certain usecases. It would
> help to put in a fix in place first and then follow that up with these
> cleanups.
On 02/26/2015 11:01 AM, Preeti U Murthy wrote:
> On 02/23/2015 11:03 PM, Nicolas Pitre wrote:
>> On Mon, 23 Feb 2015, Nicolas Pitre wrote:
>>
>>> On Mon, 23 Feb 2015, Peter Zijlstra wrote:
>>>
The reported function that fails: bL_switcher_restore_cpus() is called
in the error paths of the
On 02/23/2015 11:03 PM, Nicolas Pitre wrote:
> On Mon, 23 Feb 2015, Nicolas Pitre wrote:
>
>> On Mon, 23 Feb 2015, Peter Zijlstra wrote:
>>
>>> The reported function that fails: bL_switcher_restore_cpus() is called
>>> in the error paths of the former and the main path in the latter to make
>>> th
On Mon, 23 Feb 2015, Nicolas Pitre wrote:
> On Mon, 23 Feb 2015, Peter Zijlstra wrote:
>
> > The reported function that fails: bL_switcher_restore_cpus() is called
> > in the error paths of the former and the main path in the latter to make
> > the 'stolen' cpus re-appear.
> >
> > The patch in q
On Mon, 23 Feb 2015, Peter Zijlstra wrote:
> In any case, having had a second look I think I might have some ideas:
>
> - bL_switcher_enable() -- enables the whole switcher thing and
>disables half the cpus with hot-un-plug, creates a mapping etc..
>
> - bL_switcher_disable() -- disabled t
On Sat, Feb 21, 2015 at 12:45:51PM -0500, Nicolas Pitre wrote:
> > I'm having a very hard time trying to follow wth this thing all is
> > doing; its using hotplug but its also doing magic with cpu_suspend().
>
> You're fully aware of the on-going work on the scheduler to better
> support the big.
On Sat, 21 Feb 2015, Peter Zijlstra wrote:
> On Thu, Feb 19, 2015 at 12:51:52PM -0500, Nicolas Pitre wrote:
> >
> > This breaks the b.L switcher disabling code which essentially does:
> >
> > static void bL_switcher_restore_cpus(void)
> > {
> > int i;
> >
> > for_each_cpu(i, &bL
On Thu, Feb 19, 2015 at 12:51:52PM -0500, Nicolas Pitre wrote:
>
> This breaks the b.L switcher disabling code which essentially does:
>
> static void bL_switcher_restore_cpus(void)
> {
> int i;
>
> for_each_cpu(i, &bL_switcher_removed_logical_cpus) {
> struct dev
On Mon, 16 Feb 2015, Peter Zijlstra wrote:
> From: Thomas Gleixner
>
> Preeti reported a cpu down race with hrtimer based broadcasting:
>
> Assume CPU1 is the CPU which holds the hrtimer broadcasting duty
> before it is taken down.
>
> CPU0 CPU1
> cpu_down()
>
On Thu, Feb 19, 2015 at 12:31:53PM +0530, Preeti U Murthy wrote:
> On 02/18/2015 06:36 PM, Peter Zijlstra wrote:
> > On Wed, Feb 18, 2015 at 08:40:52AM +0530, Preeti U Murthy wrote:
> >>
> >> Look at the changelog,
> >
> > Heh, yah, clearly I tl;dr'd that. Indeed.
> >
> >> it explains why tick_t
On 02/18/2015 06:36 PM, Peter Zijlstra wrote:
> On Wed, Feb 18, 2015 at 08:40:52AM +0530, Preeti U Murthy wrote:
>>
>> Look at the changelog,
>
> Heh, yah, clearly I tl;dr'd that. Indeed.
>
>> it explains why tick_takeover must be called
>> *before* __cpu_die().
>
> Since you reported this, ca
On Wed, Feb 18, 2015 at 08:40:52AM +0530, Preeti U Murthy wrote:
>
> Look at the changelog,
Heh, yah, clearly I tl;dr'd that. Indeed.
> it explains why tick_takeover must be called
> *before* __cpu_die().
Since you reported this, can you test if things work if you move that
function call to b
On 02/17/2015 04:09 PM, Peter Zijlstra wrote:
>> [PATCH 11/35] clockevents: Cleanup dead cpu explicitely
n Tue, Feb 17, 2015 at 09:33:45AM +0530, Preeti U Murthy wrote:
>> On 02/16/2015 05:45 PM, Peter Zijlstra wrote:
>>
From: Thomas Gleixner
>>
@@ -428,7 +428,7 @@ static int __ref _cp
On Tue, Feb 17, 2015 at 09:33:45AM +0530, Preeti U Murthy wrote:
> On 02/16/2015 05:45 PM, Peter Zijlstra wrote:
>
> >> From: Thomas Gleixner
>
> >> @@ -428,7 +428,7 @@ static int __ref _cpu_down(unsigned int
> >>__cpu_die(cpu);
> >>
> >>/* CPU is completely dead: tell everyone. Too lat
On 02/16/2015 05:45 PM, Peter Zijlstra wrote:
>> From: Thomas Gleixner
>> @@ -428,7 +428,7 @@ static int __ref _cpu_down(unsigned int
>> __cpu_die(cpu);
>>
>> /* CPU is completely dead: tell everyone. Too late to complain. */
>>- tick_cleanup_dead_cpu(cpu);
>>+ tick_takeover(c
From: Thomas Gleixner
Preeti reported a cpu down race with hrtimer based broadcasting:
Assume CPU1 is the CPU which holds the hrtimer broadcasting duty
before it is taken down.
CPU0CPU1
cpu_down()
takedown_cpu()
20 matches
Mail list logo
