Message-ID: <4F578388.7050603@linux.vnet.ibm.com>
Date:	Wed, 07 Mar 2012 21:19:28 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Konstantin Khlebnikov <khlebnikov@...nvz.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"prashanth@...ux.vnet.ibm.com" <prashanth@...ux.vnet.ibm.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux PM mailing list <linux-pm@...r.kernel.org>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	"paulmck@...ux.vnet.ibm.com >> \"Paul E. McKenney\"" 
	<paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH bisected regression] sched: rebuild sched domains at suspend/resume

On 03/07/2012 09:10 PM, Konstantin Khlebnikov wrote:

> Srivatsa S. Bhat wrote:
>> On 03/07/2012 02:15 AM, Konstantin Khlebnikov wrote:
>>
>>> This is fix for suspend/resume regression introduced in commit
>>> 8f2f748b0656
>>> ("CPU hotplug, cpusets, suspend: Don't touch cpusets during
>>> suspend/resume")
>>> Without this patch suspend always hangs on my thinkpad x220 (2 x CPU
>>> * HT).
>>>
>>
>>
>> Hey, with commit 8f2f748b0656, suspend/resume works perfectly for me!
>> I ran it
>> multiple times just to make sure, and everything worked just great.
>>
>> Apart from that, I even tried suspend/resume after building the kernel
>> with
>> and without CONFIG_CPUSETS. Both cases worked perfectly.
>>
>> So, I am really surprised at what you stated above. Are you *really*
>> sure you
>> are facing suspend hangs *because* of the above commit?
>>
>> And AFAICS hardware doesn't matter for the code in question, but in
>> any case,
>> the laptop on which I tested it is:
>> Thinkpad T420 (Intel core i5-2540M), 2 cores * HT (total 4 logical cpus).
>>
>> Also, the patch you posted here doesn't make much sense.. nor does it
>> give a
>> clue as to what might be wrong at your end (if anything is really
>> wrong, that
>> is). Do you have CONFIG_CPUSETS set or unset? Could you share your
>> .config?
> 
> my kernel config in attachment. CONFIG_CPUSETS=n
> 
>>
>> Coming to your patch, assuming you have CONFIG_CPUSETS enabled, then,
>> calling rebuild_sched_domains() at that point is useless because the
>> cpusets
>> weren't changed at all. So generate_sched_domains() would generate the
>> same
>> sched domain partitions that is already there.. And hence
>> partition_sched_domains() would essentially do nothing.. no sched
>> domain is
>> destroyed, and no new domains are created.
>>
>> However, if CONFIG_CPUSETS is unset, then, before commit 8f2f748b0656,
>> partition_sched_domains(1, NULL, NULL) would have been invoked, thus
>> rebuilding
>> a single sched domain. And that is why I specifically also tested commit
>> 8f2f748b0656 with CONFIG_CPUSETS unset - and that also worked fine (as I
>> mentioned above).
>>
>> So could you please check again?
>>
>> By the way, you can use the pm-test framework (see
>> Documentation/power/basic-
>> pm-debugging.txt) to pin-point which stage is causing the hang.
>> Specifically, the stage where CPU hotplug is done is 'processors'.
>>
>> So you should probably try out this level:
>> # echo processors>  /sys/power/pm_test
>> # echo mem>  /sys/power/state
>>
>> Replacing processors with core enables even deeper level suspend testing.
> 
> Your patch has obvious side-effect.
> Bug reproducing is very stable, it disappears if revert your patch or
> apply mine.
> Problem may be not in your patch, it may only trigger some longstanding
> bug.


Thanks a lot for the confirmation! Let us revert commit 8f2f748b0656 then.

Regards,

Srivatsa S. Bhat

--
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