Re: [PATCH v3 5/5] cpusets, suspend: Save and restore cpusets duringsuspend/resume

[Srivatsa S. Bhat]

On 05/17/2012 02:54 AM, Peter Zijlstra wrote:

> On Wed, 2012-05-16 at 03:46 +0530, Srivatsa S. Bhat wrote:
>>
>> However, the cpu_active_mask was introduced to handle situations where hotplug
>> transition is still in progress, and the scheduler needs to take appropriate
>> decisions even with some of its data-structures in an inconsistent/stale state.
>> But once the hotplug operation is completed, the scheduler doesn't need to
>> depend on cpu_active_mask.
> 
>> (And on those lines, making the scheduler work correctly even in such cases
>> is only a good-to-have as a robustness measure and not a "bugfix".) 
> 
> I think those 2(?) cases you found not covered by active mask could
> actually happen during a hotplug. So far they simply haven't.
> 


Yes, it could happen during a hotplug too. And its on my todo list to fix.

(But the point I was trying to make was that keeping the sched domains outdated
across multiple hotplug operations isn't really correct.)

Anyway, I think this is the state where the discussion stands atm:

1. We are not going to alter how cpusets are handled during regular cpu hotplug.
   We will do a suspend/resume-only fix for cpusets.
   David Rientjes said that this can probably be argued about endlessly, but he
   has no objections against doing it this way.

2. David Rientjes pointed out that explicit save and restore for suspend/resume
   needs a new per-cpuset cpu mask and he would prefer a design where we wouldn't
   need a new per-cpuset mask.
   Such a design is possible, by building a single sched domain (ignoring cpuset
   configurations, by using partition_sched_domains(1, NULL, NULL)) throughout
   suspend/resume cpu hotplug operations, and then restoring the original sched
   domain tree by looking up the cpusets, towards end of resume (last online
   operation).
   
   The frozen userspace won't notice any of this.

3. David had some comments/suggestions about some patches in this series.

So, I'll go with the design mentioned in 2, and address 3 and spin out a new
version.

Regards,
Srivatsa S. Bhat

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/