Re: [Xen-devel] [PATCH v5 0/8] Memory scrubbing from idle loop

2017-06-23 Thread Boris Ostrovsky 



On 06/23/2017 09:22 AM, Jan Beulich wrote:

On 23.06.17 at 15:11,  wrote:

On 06/23/2017 05:36 AM, Jan Beulich wrote:

On 22.06.17 at 20:57,  wrote:

Deferred:
* Per-node heap locks. In addition to (presumably) improving performance in
general, once they are available we can parallelize scrubbing further by
allowing more than one core per node to do idle loop scrubbing.


I don't understand: A per-node lock still calls for just one CPU
doing the scrubbing on that node, in order to not congest the
lock.



Is this necessarily true? Maybe not allow all cores on a node to scrub
but I'd think having more than one core do the work may be beneficial.
Don't forget that actual scrubbing is performed without holding locks.
We only grab the lock to find dirty buddies in the heap.


Hmm, true, but then I still don't see the connection between
breaking up the lock and parallelizing scrubbing.


With a single heap lock we might indeed start seeing lock contention 
when multiple CPUs from many nodes are scrubbing. Making it per-node 
should lessen the pressure.


-boris

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] Memory scrubbing from idle loop

2017-06-23 Thread Jan Beulich 
>>> On 23.06.17 at 15:11,  wrote:
> On 06/23/2017 05:36 AM, Jan Beulich wrote:
> On 22.06.17 at 20:57,  wrote:
>>> Deferred:
>>> * Per-node heap locks. In addition to (presumably) improving performance in
>>>general, once they are available we can parallelize scrubbing further by
>>>allowing more than one core per node to do idle loop scrubbing.
>> 
>> I don't understand: A per-node lock still calls for just one CPU
>> doing the scrubbing on that node, in order to not congest the
>> lock.
> 
> 
> Is this necessarily true? Maybe not allow all cores on a node to scrub 
> but I'd think having more than one core do the work may be beneficial. 
> Don't forget that actual scrubbing is performed without holding locks. 
> We only grab the lock to find dirty buddies in the heap.

Hmm, true, but then I still don't see the connection between
breaking up the lock and parallelizing scrubbing.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] Memory scrubbing from idle loop

2017-06-23 Thread Boris Ostrovsky 



On 06/23/2017 05:36 AM, Jan Beulich wrote:

On 22.06.17 at 20:57,  wrote:

Deferred:
* Per-node heap locks. In addition to (presumably) improving performance in
   general, once they are available we can parallelize scrubbing further by
   allowing more than one core per node to do idle loop scrubbing.


I don't understand: A per-node lock still calls for just one CPU
doing the scrubbing on that node, in order to not congest the
lock.



Is this necessarily true? Maybe not allow all cores on a node to scrub 
but I'd think having more than one core do the work may be beneficial. 
Don't forget that actual scrubbing is performed without holding locks. 
We only grab the lock to find dirty buddies in the heap.



-boris



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 0/8] Memory scrubbing from idle loop

2017-06-23 Thread Jan Beulich 
>>> On 22.06.17 at 20:57,  wrote:
> Deferred:
> * Per-node heap locks. In addition to (presumably) improving performance in
>   general, once they are available we can parallelize scrubbing further by
>   allowing more than one core per node to do idle loop scrubbing.

I don't understand: A per-node lock still calls for just one CPU
doing the scrubbing on that node, in order to not congest the
lock.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel