[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 0/2] Boot time cpupools


  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Wed, 17 Nov 2021 12:07:21 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8CspX5/HLzX3A7h9VuLLEr57x1ohmWzgwzH5nJmCNnE=; b=oAWAssQP8cPz3PIrngX8nikldSqyOlhajkR6DoGIkdsW2tPFyk97lK0LTPtSh0GbO9HPBdNnTCGObSMFafXs82vlvWd6yscuLpWK9r3FgtFiXYaq3fzWiKaZnOF5/cbkHJXKVdlguXBOFaVxOODnHBsOWTyW4mL/uneF6SJtCInR9SMpJ6/3n6YcM2dE3D6qp6w/CAHub2WVKvdZ7iMSk+YlRJ0AV9PheeKkQy5G+zdxsSQ8rBhBDBiyRmi5adBNh++A3AvCX1EF1OcalVmyONr4oORcbrcXSwm9pCfqAA0YFMQobNOoWJjXSi+FO/efQHM/kcxifm3MpExQgHVr8A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JWTtYeXZJENnDXDvelMebshPJv7BCOPd87Z+eBAie577mB8RqZ6DjU5/AtwBpx6RW1+xpp8feDzRTOMNQ4an2KlK6OWUXsBdqVmK2OearJvTt8NZB9mtXV9czA9u59WNYm8rAJlR0Jq/EKvx8xwirDQ0F74wJmVeuIO2CXEwL3GQuFqFkH4Ae2kBPZkEFqXIvyPbIwG09i0CDs1jMdlstoLywfPJbj4Ppi1KCJi/6uAAaopFhaMxWo67QKu2SRKwBEeDZ8FzExTMrI+nVP75uG4zd1isHgZRfyqSTo51RopR3vq/bgqftlYsQ4rxxDFYIfFDskCe+EkxAOhlhUPTRw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Luca Fancellu <Luca.Fancellu@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Wed, 17 Nov 2021 12:07:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHX25mOHH0z58pAdkqC6AziO7R1GqwHg+AAgAAN94CAAAkVgIAABTgA
  • Thread-topic: [RFC PATCH 0/2] Boot time cpupools

Hi Julien,

> On 17 Nov 2021, at 11:48, Julien Grall <julien@xxxxxxx> wrote:
> 
> On 17/11/2021 11:16, Bertrand Marquis wrote:
>> Hi Julien,
> 
> Hi,
> 
>>> On 17 Nov 2021, at 10:26, Julien Grall <julien@xxxxxxx> wrote:
>>> 
>>> Hi Luca,
>>> 
>>> On 17/11/2021 09:57, Luca Fancellu wrote:
>>>> Currently Xen creates a default cpupool0 that contains all the cpu brought 
>>>> up
>>>> during boot and it assumes that the platform has only one kind of CPU.
>>>> This assumption does not hold on big.LITTLE platform, but putting different
>>>> type of CPU in the same cpupool can result in instability and security 
>>>> issues
>>>> for the domains running on the pool.
>>> 
>>> I agree that you can't move a LITTLE vCPU to a big pCPU. However...
>>> 
>>>> For this reason this serie introduces an architecture specific way to 
>>>> create
>>>> different cpupool at boot time, this is particularly useful on ARM 
>>>> big.LITTLE
>>>> platform where there might be the need to have different cpupools for each 
>>>> type
>>>> of core, but also systems using NUMA can have different cpu pool for each 
>>>> node.
>>> 
>>> ... from my understanding, all the vCPUs of a domain have to be in the same 
>>> cpupool. So with this approach it is not possible:
>>>   1) to have a mix of LITTLE and big vCPUs in the domain
>>>   2) to create a domain spanning across two NUMA nodes
>>> 
>>> So I think we need to make sure that any solutions we go through will not 
>>> prevent us to implement those setups.
>> The point of this patch is to make all cores available without breaking the 
>> current behaviour of existing system.
> 
> I might be missing some context here. By breaking current behavior, do you 
> mean user that may want to add "hmp-unsafe" on the command line?

Right, with hmp-unsafe the behaviour is now the same as without, only extra 
cores are parked in other cpupools.

So you have a point in fact that behaviour is changed for someone who was using 
hmp-unsafe before if this is activated.
The command line argument suggested by Jurgen definitely makes sense here.

We could instead do the following:
- when this is activated in the configuration, boot all cores and park them in 
different pools (depending on command line argument). Current behaviour not 
change if other pools are not used (but more cores will be on in xen)
- when hmp-unsafe is on, this feature will be turned of (if activated in 
configuration) and all cores would be added in the same pool.

What do you think ?

Cheers
Bertrand

> 
> Cheers,
> 
> -- 
> Julien Grall




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.