[Xen-devel] Ping²: [PATCH 1/2] core-parking: interact with runtime SMT-disabling

[Xen-devel] Ping²: [PATCH 1/2] core-parking: interact with runtime SMT-disabling

[Jan Beulich]

>>> On 27.05.19 at 11:36,  wrote:
>>>> On 12.04.19 at 13:41,  wrote:
> >>>> On 11.04.19 at 21:06, <andrew.cooper3@citrix.com> wrote:
> > > On 11/04/2019 13:45, Jan Beulich wrote:
> > >> When disabling SMT at runtime, secondary threads should no longer be
> > >> candidates for bringing back up in response to _PUD ACPI events. Purge
> > >> them from the tracking array.
> > >>
> > >> Doing so involves adding locking to guard accounting data in the core
> > >> parking code. While adding the declaration for the lock take the liberty
> > >> to drop two unnecessary forward function declarations.
> > >>
> > >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > > 
> > > I can certainly appreciate these arguments, but surely the converse is
> > > true.  When SMT-enable is used, the newly-onlined threads are now
> > > eligible to be parked.
> > 
> > And nothing will keep them from getting parked.
> > 
> > > At the moment, this looks asymetric.
> > 
> > It does, but that's a result of core_parking.c only recording CPUs
> > it has parked, not ones it could park.
> 
> Did my responses address your concerns?
> 
> Jan
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Ping³: [PATCH 1/2] core-parking: interact with runtime SMT-disabling

[Jan Beulich]

On 03.07.2019 13:29, Jan Beulich wrote:
>>>> On 27.05.19 at 11:36,  wrote:
>>>>> On 12.04.19 at 13:41,  wrote:
>>>>>> On 11.04.19 at 21:06, <andrew.cooper3@citrix.com> wrote:
>>>> On 11/04/2019 13:45, Jan Beulich wrote:
>>>>> When disabling SMT at runtime, secondary threads should no longer be
>>>>> candidates for bringing back up in response to _PUD ACPI events. Purge
>>>>> them from the tracking array.
>>>>>
>>>>> Doing so involves adding locking to guard accounting data in the core
>>>>> parking code. While adding the declaration for the lock take the liberty
>>>>> to drop two unnecessary forward function declarations.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>>>
>>>> I can certainly appreciate these arguments, but surely the converse is
>>>> true.  When SMT-enable is used, the newly-onlined threads are now
>>>> eligible to be parked.
>>>
>>> And nothing will keep them from getting parked.
>>>
>>>> At the moment, this looks asymetric.
>>>
>>> It does, but that's a result of core_parking.c only recording CPUs
>>> it has parked, not ones it could park.
>>
>> Did my responses address your concerns?
>>
>> Jan

Ping?

Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Ping: [PATCH 1/2] core-parking: interact with runtime SMT-disabling

[Jan Beulich]

>>> On 12.04.19 at 13:41,  wrote:
>>>> On 11.04.19 at 21:06, <andrew.cooper3@citrix.com> wrote:
> > On 11/04/2019 13:45, Jan Beulich wrote:
> >> When disabling SMT at runtime, secondary threads should no longer be
> >> candidates for bringing back up in response to _PUD ACPI events. Purge
> >> them from the tracking array.
> >>
> >> Doing so involves adding locking to guard accounting data in the core
> >> parking code. While adding the declaration for the lock take the liberty
> >> to drop two unnecessary forward function declarations.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> > 
> > I can certainly appreciate these arguments, but surely the converse is
> > true.  When SMT-enable is used, the newly-onlined threads are now
> > eligible to be parked.
> 
> And nothing will keep them from getting parked.
> 
> > At the moment, this looks asymetric.
> 
> It does, but that's a result of core_parking.c only recording CPUs
> it has parked, not ones it could park.

Did my responses address your concerns?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel