From: konrad wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
Andy Lutomirski <luto@amacapital.net>,
Pavel Emelyanov <xemul@parallels.com>,
Andrew Morton <akpm@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Xen-devel@lists.xen.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use
Date: Wed, 21 Aug 2013 09:53:32 -0400 [thread overview]
Message-ID: <5214C65C.8020908@oracle.com> (raw)
In-Reply-To: <5214C524.1050900@citrix.com>
On 8/21/2013 9:48 AM, David Vrabel wrote:
> All,
>
> 179ef71c (mm: save soft-dirty bits on swapped pages) introduces a new
> PTE bit on x86 _PTE_SWP_SOFT_DIRTY which has the same value as _PTE_PSE
> and _PTE_PAT.
>
> With a Xen PV guest, the use of the _PTE_PAT will result in the page
> having unexpected cachability which will introduce a range of subtle
> performance and correctness issues. Xen programs the entry 4 in the PAT
> table with WC so a page that was previously WB will end up as WC.
Especially with filesystems which would end up using those pages (as the
memory allocator
would recycle them) and with corruption in the filesystem. Took months
to figure
that out.
>
> The use of this bit also appears to preclude the use of (transparent)
> huge pages by the application. It is not clear if there is something
> else guaranteeing that that there will be no huge pages.
>
> To fix this regression I suggest one or more of:
>
> 1. If no other changes are made, at a mimimum, MEM_SOFT_DIRTY must
> require !XEN and possibly !TRANSPARENT_HUGEPAGE and !HUGETLBFS. This
> would prevent this option being enabled on the majority of standard
> Linux distributions.
>
> 2. Find a different PTE bit to (re)use.
>
> 3. Avoid clearing the soft dirty bit when repopulating a swapped out page.
>
> 4. Redesign the soft dirty tracking to not require the use of
> architecture specific PTE bits. e.g., by using a shadow set of
> structures for the soft dirty bit tracking.
Or revert this patch and in 3.12 fix it using one of the options above
or other ones.
>
> David
next prev parent reply other threads:[~2013-08-21 13:53 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-21 13:48 Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing use David Vrabel
2013-08-21 13:53 ` konrad wilk [this message]
2013-08-21 14:11 ` H. Peter Anvin
2013-08-21 14:19 ` Cyrill Gorcunov
2013-08-21 14:22 ` H. Peter Anvin
2013-08-21 14:29 ` Cyrill Gorcunov
2013-08-21 16:30 ` Linus Torvalds
2013-08-21 16:42 ` Cyrill Gorcunov
2013-08-21 23:05 ` Cyrill Gorcunov
2013-08-21 23:42 ` Andi Kleen
2013-08-22 5:49 ` Cyrill Gorcunov
2013-08-22 6:37 ` Minchan Kim
2013-08-22 13:12 ` Cyrill Gorcunov
2013-08-27 22:04 ` Benjamin Herrenschmidt
2013-08-21 14:12 ` Cyrill Gorcunov
2013-08-21 14:22 ` H. Peter Anvin
2013-08-21 14:53 ` Jan Beulich
2013-08-21 14:58 ` H. Peter Anvin
2013-08-21 15:42 ` Cyrill Gorcunov
2013-08-21 16:03 ` Jan Beulich
2013-08-21 16:19 ` Cyrill Gorcunov
2013-08-21 16:56 ` David Vrabel
2013-08-21 17:25 ` Cyrill Gorcunov
2013-08-21 18:17 ` Cyrill Gorcunov
2013-08-21 18:50 ` H. Peter Anvin
2013-08-21 19:03 ` Cyrill Gorcunov
2013-08-21 19:07 ` Andy Lutomirski
2013-08-21 19:20 ` Cyrill Gorcunov
2013-08-21 19:21 ` Pavel Emelyanov
2013-08-21 23:04 ` Linus Torvalds
2013-08-22 0:51 ` Dave Jones
2013-08-22 5:44 ` Cyrill Gorcunov
2013-08-22 6:41 ` Pavel Emelyanov
2013-08-22 7:47 ` Jan Beulich
2013-08-22 9:32 ` David Vrabel
2013-08-22 10:16 ` Pavel Emelyanov
2013-08-22 6:56 ` Jan Beulich
2013-08-22 7:03 ` Cyrill Gorcunov
2013-08-22 7:27 ` Jan Beulich
2013-08-22 11:27 ` Cyrill Gorcunov
2013-08-22 11:33 ` Jan Beulich
2013-08-22 12:18 ` Pavel Emelyanov
2013-08-21 17:28 ` Andy Lutomirski
2013-08-22 7:54 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5214C65C.8020908@oracle.com \
--to=konrad.wilk@oracle.com \
--cc=Xen-devel@lists.xen.org \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=jbeulich@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox