On Wed, Apr 09, 2014 at 11:18:27AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 08, 2014 at 05:51:23PM +0100, Mel Gorman wrote:
> > On Tue, Apr 08, 2014 at 12:02:50PM -0400, Konrad Rzeszutek Wilk wrote:
> > > .snip..
> > > > >>> David Vrabel has a patchset which I presumed would be pulled
On Tue, Apr 08, 2014 at 05:51:23PM +0100, Mel Gorman wrote:
> On Tue, Apr 08, 2014 at 12:02:50PM -0400, Konrad Rzeszutek Wilk wrote:
> > .snip..
> > > >>> David Vrabel has a patchset which I presumed would be pulled through
> > > >the
> > > >>> Xen tree this merge window:
> > > >>>
> > > >>>
On Wed, Apr 09, 2014 at 11:04:48AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 08, 2014 at 01:59:09PM -0700, H. Peter Anvin wrote:
> > On 04/08/2014 01:51 PM, Steven Noonan wrote:
> > > On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin wrote:
> > >>
> > >>
> > >> Of course, it would also be
On Tue, Apr 08, 2014 at 01:59:09PM -0700, H. Peter Anvin wrote:
> On 04/08/2014 01:51 PM, Steven Noonan wrote:
> > On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin wrote:
> >>
> >>
> >> Of course, it would also be preferable if Amazon (or anything else) didn't
> >> need Xen PV :(
> >
> > Well
On Tue, Apr 08, 2014 at 01:59:09PM -0700, H. Peter Anvin wrote:
On 04/08/2014 01:51 PM, Steven Noonan wrote:
On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin h...@zytor.com wrote:
snark
Of course, it would also be preferable if Amazon (or anything else) didn't
need Xen PV :(
Well
On Wed, Apr 09, 2014 at 11:04:48AM -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Apr 08, 2014 at 01:59:09PM -0700, H. Peter Anvin wrote:
On 04/08/2014 01:51 PM, Steven Noonan wrote:
On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin h...@zytor.com wrote:
snark
Of course, it would also be
On Tue, Apr 08, 2014 at 05:51:23PM +0100, Mel Gorman wrote:
On Tue, Apr 08, 2014 at 12:02:50PM -0400, Konrad Rzeszutek Wilk wrote:
.snip..
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
On Wed, Apr 09, 2014 at 11:18:27AM -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Apr 08, 2014 at 05:51:23PM +0100, Mel Gorman wrote:
On Tue, Apr 08, 2014 at 12:02:50PM -0400, Konrad Rzeszutek Wilk wrote:
.snip..
David Vrabel has a patchset which I presumed would be pulled through
the
On 04/08/2014 01:51 PM, Steven Noonan wrote:
> On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin wrote:
>>
>>
>> Of course, it would also be preferable if Amazon (or anything else) didn't
>> need Xen PV :(
>
> Well Amazon doesn't expose NUMA on PV, only on HVM guests.
>
Yes, but Amazon is one
On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin wrote:
>
>
> Of course, it would also be preferable if Amazon (or anything else) didn't
> need Xen PV :(
Well Amazon doesn't expose NUMA on PV, only on HVM guests.
> On April 7, 2014 9:04:53 PM PDT, Steven Noonan wrote:
>>On Mon, Apr 7, 2014 at
On 08/04/14 17:16, H. Peter Anvin wrote:
> On 04/08/2014 09:02 AM, Konrad Rzeszutek Wilk wrote:
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.
>>
On Tue, Apr 08, 2014 at 12:02:50PM -0400, Konrad Rzeszutek Wilk wrote:
> .snip..
> > >>> 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
> >
On Tue, Apr 08, 2014 at 09:16:49AM -0700, H. Peter Anvin wrote:
> On 04/08/2014 09:02 AM, Konrad Rzeszutek Wilk wrote:
> >>>
> >>> 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
On 04/08/2014 09:02 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>> 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.
>
> What about the patch that David Vrabel
.snip..
> >>> 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
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 wrote:
>On Mon, Apr 7, 2014 at 2:25 PM, Mel Gorman wrote:
>> On Mon, Apr 07, 2014 at 12:42:40PM -0700, H. Peter Anvin wrote:
>>> On 04/07/2014 12:36 PM,
On 07/04/14 20:36, 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
On 07/04/14 20:36, 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
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 ste...@uplinklabs.net wrote:
On Mon, Apr 7, 2014 at 2:25 PM, Mel Gorman mgor...@suse.de wrote:
On Mon, Apr 07, 2014 at 12:42:40PM -0700, H. Peter Anvin
.snip..
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
On 04/08/2014 09:02 AM, Konrad Rzeszutek Wilk wrote:
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.
What about the patch that David Vrabel posted:
On Tue, Apr 08, 2014 at 09:16:49AM -0700, H. Peter Anvin wrote:
On 04/08/2014 09:02 AM, Konrad Rzeszutek Wilk wrote:
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
On 08/04/14 17:16, H. Peter Anvin wrote:
On 04/08/2014 09:02 AM, Konrad Rzeszutek Wilk wrote:
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.
What about the
On Tue, Apr 08, 2014 at 12:02:50PM -0400, Konrad Rzeszutek Wilk wrote:
.snip..
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
On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin h...@zytor.com wrote:
snark
Of course, it would also be preferable if Amazon (or anything else) didn't
need Xen PV :(
Well Amazon doesn't expose NUMA on PV, only on HVM guests.
On April 7, 2014 9:04:53 PM PDT, Steven Noonan
On 04/08/2014 01:51 PM, Steven Noonan wrote:
On Tue, Apr 8, 2014 at 8:16 AM, H. Peter Anvin h...@zytor.com wrote:
snark
Of course, it would also be preferable if Amazon (or anything else) didn't
need Xen PV :(
Well Amazon doesn't expose NUMA on PV, only on HVM guests.
Yes, but Amazon
On Mon, Apr 7, 2014 at 2:25 PM, Mel Gorman 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:
>> >>>
>> >>>
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
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
> >
On 04/07/2014 08:10 AM, Mel Gorman wrote:
> +/*
> + * Software bits ignored by the page table walker
> + * At the time of writing, different levels have bits that are ignored. Due
> + * to physical address limitations, bits 52:62 should be ignored for the PMD
> + * and PTE levels and are available
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
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
> >
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
On Mon, Apr 07, 2014 at 07:28:54PM +0100, Mel Gorman wrote:
> > > I didn't bother spelling it out in case I gave the impression that I was
> > > blaming Xen for the problem. As the bit is now changes, does it help
> > > the Xen problem or cause another collision of some sort? There is no
> > >
On Mon, Apr 07, 2014 at 08:19:10PM +0400, Cyrill Gorcunov wrote:
> On Mon, Apr 07, 2014 at 04:49:35PM +0100, Mel Gorman wrote:
> > On Mon, Apr 07, 2014 at 04:32:39PM +0100, David Vrabel wrote:
> > > On 07/04/14 16:10, Mel Gorman wrote:
> > > > _PAGE_NUMA is currently an alias of _PROT_PROTNONE to
On Mon, Apr 07, 2014 at 04:49:35PM +0100, Mel Gorman wrote:
> On Mon, Apr 07, 2014 at 04:32:39PM +0100, David Vrabel wrote:
> > On 07/04/14 16:10, Mel Gorman wrote:
> > > _PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
> > > faults. As the bit is shared care is taken that
On Mon, Apr 07, 2014 at 04:32:39PM +0100, David Vrabel wrote:
> On 07/04/14 16:10, Mel Gorman wrote:
> > _PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
> > faults. As the bit is shared care is taken that _PAGE_NUMA is only used in
> > places where _PAGE_PROTNONE could not
On 07/04/14 16:10, Mel Gorman wrote:
> _PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
> faults. As the bit is shared care is taken that _PAGE_NUMA is only used in
> places where _PAGE_PROTNONE could not reach but this still causes problems
> on Xen and conceptually
_PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
faults. As the bit is shared care is taken that _PAGE_NUMA is only used in
places where _PAGE_PROTNONE could not reach but this still causes problems
on Xen and conceptually difficult.
Fundamentally, we only need the
_PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
faults. As the bit is shared care is taken that _PAGE_NUMA is only used in
places where _PAGE_PROTNONE could not reach but this still causes problems
on Xen and conceptually difficult.
Fundamentally, we only need the
On 07/04/14 16:10, Mel Gorman wrote:
_PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
faults. As the bit is shared care is taken that _PAGE_NUMA is only used in
places where _PAGE_PROTNONE could not reach but this still causes problems
on Xen and conceptually difficult.
On Mon, Apr 07, 2014 at 04:32:39PM +0100, David Vrabel wrote:
On 07/04/14 16:10, Mel Gorman wrote:
_PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
faults. As the bit is shared care is taken that _PAGE_NUMA is only used in
places where _PAGE_PROTNONE could not reach
On Mon, Apr 07, 2014 at 04:49:35PM +0100, Mel Gorman wrote:
On Mon, Apr 07, 2014 at 04:32:39PM +0100, David Vrabel wrote:
On 07/04/14 16:10, Mel Gorman wrote:
_PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA hinting
faults. As the bit is shared care is taken that _PAGE_NUMA
On Mon, Apr 07, 2014 at 08:19:10PM +0400, Cyrill Gorcunov wrote:
On Mon, Apr 07, 2014 at 04:49:35PM +0100, Mel Gorman wrote:
On Mon, Apr 07, 2014 at 04:32:39PM +0100, David Vrabel wrote:
On 07/04/14 16:10, Mel Gorman wrote:
_PAGE_NUMA is currently an alias of _PROT_PROTNONE to trap NUMA
On Mon, Apr 07, 2014 at 07:28:54PM +0100, Mel Gorman wrote:
I didn't bother spelling it out in case I gave the impression that I was
blaming Xen for the problem. As the bit is now changes, does it help
the Xen problem or cause another collision of some sort? There is no
guarantee
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
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
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
On 04/07/2014 08:10 AM, Mel Gorman wrote:
+/*
+ * Software bits ignored by the page table walker
+ * At the time of writing, different levels have bits that are ignored. Due
+ * to physical address limitations, bits 52:62 should be ignored for the PMD
+ * and PTE levels and are available for
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
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
On Mon, Apr 7, 2014 at 2:25 PM, Mel Gorman mgor...@suse.de 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
52 matches
Mail list logo
