Xen devel - Aug 2013 - Linux/x86's _PAGE_SWP_SOFT_DIRTY definition

All,

was anyone of you involved in the recent (rc5->rc6) changes here?
I''m asking because this new definition conflicts with _PAGE_PAT,
which is unused only for native Linux (and I continue to not really
understand their motivation to restrict themselves to just the four
most trivial memory types).

Jan

Jan Beulich <JBeulich@suse.com> wrote:
>All,
>
>was anyone of you involved in the recent (rc5->rc6) changes here?
>I''m asking because this new definition conflicts with _PAGE_PAT,
>which is unused only for native Linux (and I continue to not really
>understand their motivation to restrict themselves to just the four
>most trivial memory types).
>
>Jan
I have not.  Does it cause regressions?

>>> On 21.08.13 at 12:50, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> Jan Beulich <JBeulich@suse.com> wrote:
>>was anyone of you involved in the recent (rc5->rc6) changes here?
>>I''m asking because this new definition conflicts with
_PAGE_PAT,
>>which is unused only for native Linux (and I continue to not really
>>understand their motivation to restrict themselves to just the four
>>most trivial memory types).
> 
> I have not.  Does it cause regressions?
Afaict it obviously will; luckily I noticed it while merging, so I
didn''t
get to the point where any problem would be noticed.

Jan

On 21/08/13 08:42, Jan Beulich wrote:
> All,
> 
> was anyone of you involved in the recent (rc5->rc6) changes here?
> I''m asking because this new definition conflicts with _PAGE_PAT,
> which is unused only for native Linux (and I continue to not really
> understand their motivation to restrict themselves to just the four
> most trivial memory types).
I was not aware of it and that just looks broken -- not just Xen but it
looks like it wouldn''t work with (transparent) huge pages either.

The soft dirty tracking was introduced (in 3.11-rc1) by 0f8975ec4 (mm:
soft-dirty bits for user memory changes tracking) and the problematic
patch adding the conflicting PTE bit is 179ef71cb (mm: save soft-dirty
bits on swapped pages).

David

David Vrabel <david.vrabel@citrix.com> wrote:
>On 21/08/13 08:42, Jan Beulich wrote:
>> All,
>> 
>> was anyone of you involved in the recent (rc5->rc6) changes here?
>> I''m asking because this new definition conflicts with
_PAGE_PAT,
>> which is unused only for native Linux (and I continue to not really
>> understand their motivation to restrict themselves to just the four
>> most trivial memory types).
>
>I was not aware of it and that just looks broken -- not just Xen but it
>looks like it wouldn''t work with (transparent) huge pages either.
>
>The soft dirty tracking was introduced (in 3.11-rc1) by 0f8975ec4 (mm:
>soft-dirty bits for user memory changes tracking) and the problematic
>patch adding the conflicting PTE bit is 179ef71cb (mm: save soft-dirty
>bits on swapped pages).
>
>David
I am going to be in meetings most of today. David or Jan  would you be OK
emailing the folks who came up with the patch and the committeer to mention that
it causes a regression?

And naturally test it first with a upstream kernel?  I presume the regressions
is in the form of pages of WB becoming WC and suddenly applications failing
oddly?

On 21/08/13 12:58, Konrad Rzeszutek Wilk wrote:
> David Vrabel <david.vrabel@citrix.com> wrote:
>> On 21/08/13 08:42, Jan Beulich wrote:
>>> All,
>>>
>>> was anyone of you involved in the recent (rc5->rc6) changes
here?
>>> I''m asking because this new definition conflicts with
_PAGE_PAT,
>>> which is unused only for native Linux (and I continue to not really
>>> understand their motivation to restrict themselves to just the four
>>> most trivial memory types).
>>
>> I was not aware of it and that just looks broken -- not just Xen but it
>> looks like it wouldn''t work with (transparent) huge pages
either.
>>
>> The soft dirty tracking was introduced (in 3.11-rc1) by 0f8975ec4 (mm:
>> soft-dirty bits for user memory changes tracking) and the problematic
>> patch adding the conflicting PTE bit is 179ef71cb (mm: save soft-dirty
>> bits on swapped pages).
>>
>> David
> 
> I am going to be in meetings most of today. David or Jan  would you
> be OK emailing the folks who came up with the patch and the
> committeer to mention that it causes a regression?
> 
> And naturally test it first with a upstream kernel?  I presume the
> regressions is in the form of pages of WB becoming WC and suddenly
> applications failing oddly?
It''s not clear how a test case to show the regression can be reliably
produced in a limited time.  The failures from using WC instead of WB
will be pretty subtle.

David