On Thu, Jan 25, 2018 at 02:03:35PM +, George Dunlap wrote:
> On Thu, Jan 25, 2018 at 9:14 AM, Roger Pau Monné wrote:
> > On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
> >> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne
> >>
On Thu, Jan 25, 2018 at 9:14 AM, Roger Pau Monné wrote:
> On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
>> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne
>> wrote:
>> > Since VCPUOP_{up/down} already identity pins vCPU hotplug to
On Wed, Jan 24, 2018 at 06:03:28PM +, George Dunlap wrote:
> On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne wrote:
> > Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
> > hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
> > vCPU
On Wed, Jan 17, 2018 at 9:48 AM, Roger Pau Monne wrote:
> Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
> hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
> vCPU migration and should improve performance.
>
> While there also use
On Wed, Jan 17, 2018 at 09:48:11AM +, Roger Pau Monne wrote:
> Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
> hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
The description is a bit ambiguous. I read it as "the shim hotplug code
pins vcpu to pcpu
Since VCPUOP_{up/down} already identity pins vCPU hotplug to pCPU
hotplug also pin the vCPUs to the pCPUs in the scheduler. This prevent
vCPU migration and should improve performance.
While there also use __cpumask_set_cpu instead of cpumask_set_cpu,
there's no need to use the locked variant.