Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-08 Thread Chao Gao
On Mon, May 08, 2017 at 03:24:47AM -0600, Jan Beulich wrote: >(Chao Gao got lost from the recipients list again; re-adding) > On 08.05.17 at 11:13, wrote: >> On 08/05/17 17:15, Chao Gao wrote: >>> On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote: >>> On 03.05.17 at 12:08, wrot

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-08 Thread Jan Beulich
(Chao Gao got lost from the recipients list again; re-adding) >>> On 08.05.17 at 11:13, wrote: > On 08/05/17 17:15, Chao Gao wrote: >> On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote: >> On 03.05.17 at 12:08, wrote: On 02/05/17 06:45, Chao Gao wrote: > On Wed, Apr 26, 20

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-08 Thread George Dunlap
On 08/05/17 17:15, Chao Gao wrote: > On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote: > On 03.05.17 at 12:08, wrote: >>> On 02/05/17 06:45, Chao Gao wrote: On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: > On 26/04/17 01:52, Chao Gao wrote: >> I compared

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-08 Thread Chao Gao
On Mon, May 08, 2017 at 02:39:25AM -0600, Jan Beulich wrote: On 08.05.17 at 18:15, wrote: >> On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote: >> On 03.05.17 at 12:08, wrote: On 02/05/17 06:45, Chao Gao wrote: > On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-08 Thread Jan Beulich
>>> On 08.05.17 at 18:15, wrote: > On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote: > On 03.05.17 at 12:08, wrote: >>> On 02/05/17 06:45, Chao Gao wrote: On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: > On 26/04/17 01:52, Chao Gao wrote: >> I compared

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-08 Thread Chao Gao
On Wed, May 03, 2017 at 04:21:27AM -0600, Jan Beulich wrote: On 03.05.17 at 12:08, wrote: >> On 02/05/17 06:45, Chao Gao wrote: >>> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: On 26/04/17 01:52, Chao Gao wrote: > I compared the maximum of #entry in one list and #ev

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-03 Thread Jan Beulich
>>> On 03.05.17 at 12:08, wrote: > On 02/05/17 06:45, Chao Gao wrote: >> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: >>> On 26/04/17 01:52, Chao Gao wrote: I compared the maximum of #entry in one list and #event (adding entry to PI blocking list) with and without the t

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-03 Thread George Dunlap
On 02/05/17 06:45, Chao Gao wrote: > On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: >> On 26/04/17 01:52, Chao Gao wrote: >>> I compared the maximum of #entry in one list and #event (adding entry to >>> PI blocking list) with and without the three latter patches. Here >>> is the res

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-05-01 Thread Chao Gao
On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: >On 26/04/17 01:52, Chao Gao wrote: >> I compared the maximum of #entry in one list and #event (adding entry to >> PI blocking list) with and without the three latter patches. Here >> is the result: >> --

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-04-27 Thread Chao Gao
On Thu, Apr 27, 2017 at 10:44:26AM +0100, George Dunlap wrote: >On Thu, Apr 27, 2017 at 1:43 AM, Chao Gao wrote: >> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: >>>On 26/04/17 01:52, Chao Gao wrote: VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU r

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-04-27 Thread George Dunlap
On Thu, Apr 27, 2017 at 1:43 AM, Chao Gao wrote: > On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: >>On 26/04/17 01:52, Chao Gao wrote: >>> VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU >>> running on the pCPU. Theoretically, there are 32K domain on single >>

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-04-27 Thread Chao Gao
On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote: >On 26/04/17 01:52, Chao Gao wrote: >> VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU >> running on the pCPU. Theoretically, there are 32K domain on single >> host, 128 vCPUs per domain. If all vCPUs are blocked o

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-04-26 Thread George Dunlap
On 26/04/17 01:52, Chao Gao wrote: > VT-d PI introduces a per-pCPU blocking list to track the blocked vCPU > running on the pCPU. Theoretically, there are 32K domain on single > host, 128 vCPUs per domain. If all vCPUs are blocked on the same pCPU, > 4M vCPUs are in the same list. Travelling this i

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-04-26 Thread Jan Beulich
>>> On 26.04.17 at 05:30, wrote: > On Wed, Apr 26, 2017 at 02:19:22AM -0600, Jan Beulich wrote: > On 26.04.17 at 02:52, wrote: >>> Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline >>> pCPUs, which can theoretically decrease the maximum of #entry >>> in the list by N times. N

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-04-26 Thread Chao Gao
On Wed, Apr 26, 2017 at 02:19:22AM -0600, Jan Beulich wrote: On 26.04.17 at 02:52, wrote: >> Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline >> pCPUs, which can theoretically decrease the maximum of #entry >> in the list by N times. N is #pCPU. > >Why randomly? Shouldn't cur

Re: [Xen-devel] [PATCH 0/4] mitigate the per-pCPU blocking list may be too long

2017-04-26 Thread Jan Beulich
>>> On 26.04.17 at 02:52, wrote: > Patch 2/4 randomly distritbutes entries (vCPUs) among all oneline > pCPUs, which can theoretically decrease the maximum of #entry > in the list by N times. N is #pCPU. Why randomly? Shouldn't current list length determine which CPU(s) to prefer? Jan _