> On Jan 19, 2018, at 6:12 PM, Christopher Lameter wrote:
>
> On Thu, 18 Jan 2018, Henry Willard wrote:
>
>> If MPOL_MF_LAZY were allowed and specified things would not work
>> correctly. change_pte_range() is unaware of and can’t honor the
>> difference between MPOL_MF_MOVE_ALL and MPOL_MF_MO
On Thu, 18 Jan 2018, Henry Willard wrote:
> If MPOL_MF_LAZY were allowed and specified things would not work
> correctly. change_pte_range() is unaware of and can’t honor the
> difference between MPOL_MF_MOVE_ALL and MPOL_MF_MOVE.
Not sure how that relates to what I said earlier... Sorry.
>
> Fo
> On Jan 17, 2018, at 10:23 AM, Christopher Lameter wrote:
>
> On Tue, 16 Jan 2018, Mel Gorman wrote:
>
>> My main source of discomfort is the fact that this is permanent as two
>> processes perfectly isolated but with a suitably shared COW mapping
>> will never migrate the data. A potential i
On Tue, 16 Jan 2018, Mel Gorman wrote:
> My main source of discomfort is the fact that this is permanent as two
> processes perfectly isolated but with a suitably shared COW mapping
> will never migrate the data. A potential improvement to get the reported
> bandwidth up in the test program would
> On Jan 16, 2018, at 1:26 PM, Mel Gorman wrote:
>
> On Tue, Jan 16, 2018 at 11:28:44AM -0800, Henry Willard wrote:
>> Workloads consisting of a large number processes running the same program
>> with a large shared data section may suffer from excessive numa balancing
>> page migration of the
On Tue, Jan 16, 2018 at 11:28:44AM -0800, Henry Willard wrote:
> Workloads consisting of a large number processes running the same program
> with a large shared data section may suffer from excessive numa balancing
> page migration of the pages in the shared data section. This shows up as
> high I/
6 matches
Mail list logo
