[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5214C524.1050900@citrix.com>
Date: Wed, 21 Aug 2013 14:48:20 +0100
From: David Vrabel <david.vrabel@...rix.com>
To: Cyrill Gorcunov <gorcunov@...il.com>
CC: Andy Lutomirski <luto@...capital.net>,
Pavel Emelyanov <xemul@...allels.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
<Xen-devel@...ts.xen.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Jan Beulich <jbeulich@...e.com>
Subject: Regression: x86/mm: new _PTE_SWP_SOFT_DIRTY bit conflicts with existing
use
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.
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.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists