On 06/23/2014 06:08 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote:
>> On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
The following patch does the always eager allocation. It's a fixup of
Suresh's original patch.
>>>
>>>
On 06/23/2014 06:08 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote:
On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
The following patch does the always eager allocation. It's a fixup of
Suresh's original patch.
Hey Peter,
I think
On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote:
> On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
> >>
> >> The following patch does the always eager allocation. It's a fixup of
> >> Suresh's original patch.
> >>
> >
> > Hey Peter,
> >
> > I think this is the solution you
On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote:
On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
The following patch does the always eager allocation. It's a fixup of
Suresh's original patch.
Hey Peter,
I think this is the solution you were looking for?
Sounds good.
On March 19, 2014 5:00:11 PM PDT, Greg Kroah-Hartman
wrote:
>On Sun, Mar 16, 2014 at 09:23:01PM -0700, H. Peter Anvin wrote:
>> On 03/16/2014 09:12 PM, Sarah Newman wrote:
>> >
>> > Unconditional eager allocation works. Can xen users count on this
>being included and applied to
On Sun, Mar 16, 2014 at 09:23:01PM -0700, H. Peter Anvin wrote:
> On 03/16/2014 09:12 PM, Sarah Newman wrote:
> >
> > Unconditional eager allocation works. Can xen users count on this being
> > included and applied to the
> > stable kernels?
> >
>
> I don't know. If we state that it is a bug
On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
>>
>> The following patch does the always eager allocation. It's a fixup of
>> Suresh's original patch.
>>
>
> Hey Peter,
>
> I think this is the solution you were looking for?
>
> Or are there some other subtle issues that you think lurk
On Mon, Mar 17, 2014 at 01:29:03PM +, David Vrabel wrote:
> On 17/03/14 03:43, H. Peter Anvin wrote:
> > On 03/16/2014 08:35 PM, Sarah Newman wrote:
> >> Can you please review my patch first? It's only enabled when absolutely
> >> required.
> >
> > It doesn't help. It means you're running
On Mon, Mar 17, 2014 at 01:29:03PM +, David Vrabel wrote:
On 17/03/14 03:43, H. Peter Anvin wrote:
On 03/16/2014 08:35 PM, Sarah Newman wrote:
Can you please review my patch first? It's only enabled when absolutely
required.
It doesn't help. It means you're running on Xen, and
On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
The following patch does the always eager allocation. It's a fixup of
Suresh's original patch.
Hey Peter,
I think this is the solution you were looking for?
Or are there some other subtle issues that you think lurk around?
Ah, I
On Sun, Mar 16, 2014 at 09:23:01PM -0700, H. Peter Anvin wrote:
On 03/16/2014 09:12 PM, Sarah Newman wrote:
Unconditional eager allocation works. Can xen users count on this being
included and applied to the
stable kernels?
I don't know. If we state that it is a bug fix for Xen
Sounds good.
On March 19, 2014 5:00:11 PM PDT, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sun, Mar 16, 2014 at 09:23:01PM -0700, H. Peter Anvin wrote:
On 03/16/2014 09:12 PM, Sarah Newman wrote:
Unconditional eager allocation works. Can xen users count on this
being included
On 03/18/2014 11:17 AM, Sarah Newman wrote:
>
> Should or has there been a review of the current xen PVABI to look for any
> other such deviations?
>
It would be a very good thing to do. First of all, the PVABI needs to
be **documented** because without that there is no hope. I would like
to
On 03/17/2014 10:14 AM, George Dunlap wrote:
> On 03/17/2014 05:05 PM, Jan Beulich wrote:
> On 17.03.14 at 17:55, "H. Peter Anvin" wrote:
>>> So if this interface wasn't an accident it was active negligence and
>>> incompetence.
>> I don't think so - while it (as we now see) disallows certain
* H. Peter Anvin wrote:
> On 03/17/2014 10:05 AM, Jan Beulich wrote:
> >
> > I don't think so - while it (as we now see) disallows certain things
> > inside the guest, back at the time when this was designed there was
> > no sign of any sort of allocation/scheduling being done inside the
> >
* H. Peter Anvin h...@zytor.com wrote:
On 03/17/2014 10:05 AM, Jan Beulich wrote:
I don't think so - while it (as we now see) disallows certain things
inside the guest, back at the time when this was designed there was
no sign of any sort of allocation/scheduling being done inside the
On 03/17/2014 10:14 AM, George Dunlap wrote:
On 03/17/2014 05:05 PM, Jan Beulich wrote:
On 17.03.14 at 17:55, H. Peter Anvin h...@zytor.com wrote:
So if this interface wasn't an accident it was active negligence and
incompetence.
I don't think so - while it (as we now see) disallows certain
On 03/18/2014 11:17 AM, Sarah Newman wrote:
Should or has there been a review of the current xen PVABI to look for any
other such deviations?
It would be a very good thing to do. First of all, the PVABI needs to
be **documented** because without that there is no hope. I would like
to
On 03/17/2014 05:05 PM, Jan Beulich wrote:
On 17.03.14 at 17:55, "H. Peter Anvin" wrote:
On 03/17/2014 05:19 AM, George Dunlap wrote:
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
workaround for the legacy
On 03/17/2014 10:05 AM, Jan Beulich wrote:
>
> I don't think so - while it (as we now see) disallows certain things
> inside the guest, back at the time when this was designed there was
> no sign of any sort of allocation/scheduling being done inside the
> #NM handler. And furthermore, a PV
>>> On 17.03.14 at 17:55, "H. Peter Anvin" wrote:
> On 03/17/2014 05:19 AM, George Dunlap wrote:
>> On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
>>> No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
> workaround for the legacy hypervisor versions.
>>
>> The
On 03/17/2014 05:19 AM, George Dunlap wrote:
> On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
>> No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
>> workaround for the legacy hypervisor versions.
>
> The interface wasn't an accident. In the most common case
On 17/03/14 03:43, H. Peter Anvin wrote:
> On 03/16/2014 08:35 PM, Sarah Newman wrote:
>> Can you please review my patch first? It's only enabled when absolutely
>> required.
>
> It doesn't help. It means you're running on Xen, and you will have
> processes subjected to random SIGKILL because
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin wrote:
> No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
> workaround for the legacy hypervisor versions.
The interface wasn't an accident. In the most common case you'll want
to clear the bit anyway. In PV mode
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin h...@zytor.com wrote:
No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
workaround for the legacy hypervisor versions.
The interface wasn't an accident. In the most common case you'll want
to clear the bit anyway. In PV
On 17/03/14 03:43, H. Peter Anvin wrote:
On 03/16/2014 08:35 PM, Sarah Newman wrote:
Can you please review my patch first? It's only enabled when absolutely
required.
It doesn't help. It means you're running on Xen, and you will have
processes subjected to random SIGKILL because they
On 03/17/2014 05:19 AM, George Dunlap wrote:
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin h...@zytor.com wrote:
No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
workaround for the legacy hypervisor versions.
The interface wasn't an accident. In the most common
On 17.03.14 at 17:55, H. Peter Anvin h...@zytor.com wrote:
On 03/17/2014 05:19 AM, George Dunlap wrote:
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin h...@zytor.com wrote:
No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
workaround for the legacy hypervisor
On 03/17/2014 10:05 AM, Jan Beulich wrote:
I don't think so - while it (as we now see) disallows certain things
inside the guest, back at the time when this was designed there was
no sign of any sort of allocation/scheduling being done inside the
#NM handler. And furthermore, a PV
On 03/17/2014 05:05 PM, Jan Beulich wrote:
On 17.03.14 at 17:55, H. Peter Anvin h...@zytor.com wrote:
On 03/17/2014 05:19 AM, George Dunlap wrote:
On Mon, Mar 17, 2014 at 3:33 AM, H. Peter Anvin h...@zytor.com wrote:
No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
On 03/16/2014 09:12 PM, Sarah Newman wrote:
>
> Unconditional eager allocation works. Can xen users count on this being
> included and applied to the
> stable kernels?
>
I don't know. If we state that it is a bug fix for Xen it might be
possible, but it would be up to Greg (Cc:'d) and the
On 03/16/2014 08:43 PM, H. Peter Anvin wrote:
> On 03/16/2014 08:35 PM, Sarah Newman wrote:
>> Can you please review my patch first? It's only enabled when absolutely
>> required.
>
> It doesn't help. It means you're running on Xen, and you will have
> processes subjected to random SIGKILL
On 03/16/2014 08:35 PM, Sarah Newman wrote:
> Can you please review my patch first? It's only enabled when absolutely
> required.
It doesn't help. It means you're running on Xen, and you will have
processes subjected to random SIGKILL because they happen to touch the
FPU when the atomic pool
Can you please review my patch first? It's only enabled when absolutely
required.
On 03/16/2014 08:33 PM, H. Peter Anvin wrote:
> No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
> workaround for the legacy hypervisor versions.
>
> GFP_ATOMIC -> SIGKILL is definitely
Can you please review my patch first? It's only enabled when absolutely
required.
On 03/16/2014 08:33 PM, H. Peter Anvin wrote:
No, the right thing is to unf*ck the Xen braindamage and use eagerfpu as a
workaround for the legacy hypervisor versions.
GFP_ATOMIC - SIGKILL is definitely a
On 03/16/2014 08:35 PM, Sarah Newman wrote:
Can you please review my patch first? It's only enabled when absolutely
required.
It doesn't help. It means you're running on Xen, and you will have
processes subjected to random SIGKILL because they happen to touch the
FPU when the atomic pool is
On 03/16/2014 08:43 PM, H. Peter Anvin wrote:
On 03/16/2014 08:35 PM, Sarah Newman wrote:
Can you please review my patch first? It's only enabled when absolutely
required.
It doesn't help. It means you're running on Xen, and you will have
processes subjected to random SIGKILL because
On 03/16/2014 09:12 PM, Sarah Newman wrote:
Unconditional eager allocation works. Can xen users count on this being
included and applied to the
stable kernels?
I don't know. If we state that it is a bug fix for Xen it might be
possible, but it would be up to Greg (Cc:'d) and the rest of
38 matches
Mail list logo
