On Sun, Jun 23, 2013 at 1:38 PM, H. Peter Anvin wrote:
> On 06/23/2013 01:30 PM, Dave Airlie wrote:
> Why do you care about performance when PAT is disabled?
>>
>> breaking old boxes just because, is just going to get reverted when I
>> get the first regression report that you broke old boxes.
On Mon, Jun 24, 2013 at 6:58 AM, H. Peter Anvin wrote:
> On 06/23/2013 01:54 PM, Dave Airlie wrote:
breaking old boxes just because, is just going to get reverted when I
get the first regression report that you broke old boxes.
>>>
>>> Not "just because", but *if* the choice is betw
>> breaking old boxes just because, is just going to get reverted when I
>> get the first regression report that you broke old boxes.
>>
>
> Not "just because", but *if* the choice is between breaking old boxes
> and breaking new boxes I'll take the latter.
>
But Linus won't so your choice doesn't
>>> Why do you care about performance when PAT is disabled?
breaking old boxes just because, is just going to get reverted when I
get the first regression report that you broke old boxes.
Andy Lutomirski just submitted a bunch of patches to clean up the DRM
usage of mtrrs, they are in drm-next, a
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
> >
> > And as far as I could find from Intel's not-that-complete public
> > "specification updates", we are applying the errata workaround to a few more
> > processors than strictly required, b
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> > On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> >> Why do you care about performance when PAT is disabled?
> >
> > It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
>
The aliasing doesn't matter for Linux because we map the high and low half the
same.
Henrique de Moraes Holschuh wrote:
>On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>> >
>> > And as far as I could find from Intel's not-that-complete
The aliasing doesn't matter for Linux because we map the high and low half the
same.
Henrique de Moraes Holschuh wrote:
>On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>> >
>> > And as far as I could find from Intel's not-that-complete
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
> >
> > And as far as I could find from Intel's not-that-complete public
> > "specification updates", we are applying the errata workaround to a few more
> > processors than strictly required, b
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> Why do you care about performance when PAT is disabled?
It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
nobody ever took the pain to track down which ones of those actually have
PAT+MTRR aliasing bugs.
These boxes have boar
On Sun, Jun 23, 2013 at 1:38 PM, H. Peter Anvin wrote:
> On 06/23/2013 01:30 PM, Dave Airlie wrote:
> Why do you care about performance when PAT is disabled?
>>
>> breaking old boxes just because, is just going to get reverted when I
>> get the first regression report that you broke old boxes.
On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>
> And as far as I could find from Intel's not-that-complete public
> "specification updates", we are applying the errata workaround to a few more
> processors than strictly required, but since I have no idea how to write a
> test case, I
On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>
> And as far as I could find from Intel's not-that-complete public
> "specification updates", we are applying the errata workaround to a few more
> processors than strictly required, but since I have no idea how to write a
> test case, I
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> > On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> >> Why do you care about performance when PAT is disabled?
> >
> > It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
>
On Mon, Jun 24, 2013 at 6:58 AM, H. Peter Anvin wrote:
> On 06/23/2013 01:54 PM, Dave Airlie wrote:
breaking old boxes just because, is just going to get reverted when I
get the first regression report that you broke old boxes.
>>>
>>> Not "just because", but *if* the choice is betw
On 06/23/2013 01:54 PM, Dave Airlie wrote:
>>> breaking old boxes just because, is just going to get reverted when I
>>> get the first regression report that you broke old boxes.
>>>
>>
>> Not "just because", but *if* the choice is between breaking old boxes
>> and breaking new boxes I'll take the
On 06/23/2013 01:54 PM, Dave Airlie wrote:
>>> breaking old boxes just because, is just going to get reverted when I
>>> get the first regression report that you broke old boxes.
>>>
>>
>> Not "just because", but *if* the choice is between breaking old boxes
>> and breaking new boxes I'll take the
>> breaking old boxes just because, is just going to get reverted when I
>> get the first regression report that you broke old boxes.
>>
>
> Not "just because", but *if* the choice is between breaking old boxes
> and breaking new boxes I'll take the latter.
>
But Linus won't so your choice doesn't
On 06/23/2013 01:30 PM, Dave Airlie wrote:
Why do you care about performance when PAT is disabled?
>
> breaking old boxes just because, is just going to get reverted when I
> get the first regression report that you broke old boxes.
>
Not "just because", but *if* the choice is between break
On 06/23/2013 01:30 PM, Dave Airlie wrote:
Why do you care about performance when PAT is disabled?
>
> breaking old boxes just because, is just going to get reverted when I
> get the first regression report that you broke old boxes.
>
Not "just because", but *if* the choice is between break
>>> Why do you care about performance when PAT is disabled?
breaking old boxes just because, is just going to get reverted when I
get the first regression report that you broke old boxes.
Andy Lutomirski just submitted a bunch of patches to clean up the DRM
usage of mtrrs, they are in drm-next, a
On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> Why do you care about performance when PAT is disabled?
>
> It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
> nobody ever took the pain to track down which ones o
On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> Why do you care about performance when PAT is disabled?
>
> It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
> nobody ever took the pain to track down which ones o
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
> Why do you care about performance when PAT is disabled?
It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
nobody ever took the pain to track down which ones of those actually have
PAT+MTRR aliasing bugs.
These boxes have boar
Le 21/06/2013 07:00, H. Peter Anvin a écrit :
> An awful lot of drivers, mostly DRI drivers, are still mucking with
> MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
> In addition to the architecture dependency, this is really undesirable
> because MTRRs are a limited resourc
Le 21/06/2013 07:00, H. Peter Anvin a ?crit :
> An awful lot of drivers, mostly DRI drivers, are still mucking with
> MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
> In addition to the architecture dependency, this is really undesirable
> because MTRRs are a limited resourc
Why do you care about performance when PAT is disabled?
Brice Goglin wrote:
>Le 21/06/2013 07:00, H. Peter Anvin a écrit :
>> An awful lot of drivers, mostly DRI drivers, are still mucking with
>> MTRRs directly as opposed to using ioremap_wc() or similar
>interfaces.
>> In addition to the archi
Why do you care about performance when PAT is disabled?
Brice Goglin wrote:
>Le 21/06/2013 07:00, H. Peter Anvin a ?crit :
>> An awful lot of drivers, mostly DRI drivers, are still mucking with
>> MTRRs directly as opposed to using ioremap_wc() or similar
>interfaces.
>> In addition to the archi
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
Furthermore
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
Furthermore
30 matches
Mail list logo
