<snark> Of course, it would also be preferable if Amazon (or anything else) didn't need Xen PV :( On April 7, 2014 9:04:53 PM PDT, Steven Noonan <steven@xxxxxxxxxxxxxx> wrote: >On Mon, Apr 7, 2014 at 2:25 PM, Mel Gorman <mgorman@xxxxxxx> wrote: >> On Mon, Apr 07, 2014 at 12:42:40PM -0700, H. Peter Anvin wrote: >>> On 04/07/2014 12:36 PM, Cyrill Gorcunov wrote: >>> > On Mon, Apr 07, 2014 at 12:27:10PM -0700, H. Peter Anvin wrote: >>> >> On 04/07/2014 11:28 AM, Mel Gorman wrote: >>> >>> >>> >>> I had considered the soft-dirty tracking usage of the same bit. >I thought I'd >>> >>> be able to swizzle around it or a further worst case of having >soft-dirty and >>> >>> automatic NUMA balancing mutually exclusive. Unfortunately upon >examination >>> >>> it's not obvious how to have both of them share a bit and I >suspect any >>> >>> attempt to will break CRIU. In my current tree, NUMA_BALANCING >cannot be >>> >>> set if MEM_SOFT_DIRTY which is not particularly satisfactory. >Next on the >>> >>> list is examining if _PAGE_BIT_IOMAP can be used. >>> >> >>> >> Didn't we smoke the last user of _PAGE_BIT_IOMAP? >>> > >>> > Seems so, at least for non-kernel pages (not considering this bit >references in >>> > xen code, which i simply don't know but i guess it's used for >kernel pages only). >>> > >>> >>> David Vrabel has a patchset which I presumed would be pulled through >the >>> Xen tree this merge window: >>> >>> [PATCHv5 0/8] x86/xen: fixes for mapping high MMIO regions (and >remove >>> _PAGE_IOMAP) >>> >>> That frees up this bit. >>> >> >> Thanks, I was not aware of that patch. Based on it, I intend to >force >> automatic NUMA balancing to depend on !XEN and see what the reaction >is. If >> support for Xen is really required then it potentially be re-enabled >if/when >> that series is merged assuming they do not need the bit for something >else. >> > >Amazon EC2 does have large memory instance types with NUMA exposed to >the guest (e.g. c3.8xlarge, i2.8xlarge, etc), so it'd be preferable >(to me anyway) if we didn't require !XEN. -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>