From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: Linux/x86's _PAGE_SWP_SOFT_DIRTY definition
Date: Wed, 21 Aug 2013 13:38:47 +0100
Message-ID: <5214B4D7.1090404@citrix.com>
References: <52148B8D02000078000ED3C8@nat28.tlf.novell.com>
	<5214A8D9.20509@citrix.com>
	<908e833e-19e9-4fde-ab75-66554a58e30e@email.android.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1VC7gh-0002BK-Pf
	for xen-devel@lists.xenproject.org; Wed, 21 Aug 2013 12:38:59 +0000
In-Reply-To: <908e833e-19e9-4fde-ab75-66554a58e30e@email.android.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Boris Ostrovsky <boris.ostrovsky@oracle.com>, Jan Beulich <JBeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

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