lkml.org 
[lkml]   [2003]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
Date
Potentially, any address can be a candidate. If you assume a sequential
access pattern for data, addresses toward the back of the cache-line
(but not the last few bytes) are less likely to hit the errata
because hopefully the page that the cacheline is in is
already "faulted in". But that is no guarantee.


] -Rich ...
] AMD Fellow
] richard.brunner at amd com

> -----Original Message-----
> From: Jamie Lokier [mailto:jamie@shareable.org]
> Sent: Thursday, September 11, 2003 9:59 AM
> To: Andi Kleen
> Cc: Brunner, Richard; linux-kernel@vger.kernel.org;
> akpm@osdl.org; torvalds@osdl.org
> Subject: Re: [PATCH] 2.6 workaround for Athlon/Opteron prefetch errata
>
>
> Andi Kleen wrote:
> > +static int is_prefetch(struct pt_regs *regs, unsigned long addr)
>
> Do I understand that certain values of "addr" can't be due to the
> erratum?
>
> In which case, could you skip most of the is_prefetch() instruction
> decoder with a test like this?:
>
> if ((addr & 3) == 0)
> return 0;
>
> I'm not sure from the description of the erratum what, exactly, are
> the possible addresses which can appear in the fault information.
>
> -- Jamie
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.031 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site