Messages in this thread | | | Date | Wed, 07 Mar 2012 21:19:28 +0530 | From | "Srivatsa S. Bhat" <> | 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
| |