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 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 we
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 the
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 f
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 aro
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 o
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
> > #N
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 h
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 specif
>>> 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 in
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 you
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 t
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 clearing
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
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 beca
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
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
19 matches
Mail list logo
