I would expect to see dcbtst in here, no?
Nah, dcbtst is expensive (it causes some non-cheap bus
transactions) and not needed at all; dcbz is much better
(but can only be used if you kill the whole cache line;
which is true here).
Both functions (copy and clear) could stand a little loop unrol
On Mon, 2006-08-28 at 13:20 -0400, Jimi Xenidis wrote:
> On Aug 28, 2006, at 1:10 PM, Hollis Blanchard wrote:
> > Right. As long as we're changing this code, let's include copy_page().
> >
> > ... which brings us back to the original patch a) removing the call to
> > mambo_memcpy(), and b) missing
On Aug 28, 2006, at 1:10 PM, Hollis Blanchard wrote:
On Mon, 2006-08-28 at 11:58 -0400, Jimi Xenidis wrote:
On Aug 28, 2006, at 11:49 AM, Hollis Blanchard wrote:
On Mon, 2006-08-28 at 11:31 -0400, Jimi Xenidis wrote:
On Aug 28, 2006, at 10:50 AM, Hollis Blanchard wrote:
Also, it looks li
On Mon, 2006-08-28 at 11:58 -0400, Jimi Xenidis wrote:
> On Aug 28, 2006, at 11:49 AM, Hollis Blanchard wrote:
>
> > On Mon, 2006-08-28 at 11:31 -0400, Jimi Xenidis wrote:
> >> On Aug 28, 2006, at 10:50 AM, Hollis Blanchard wrote:
> >>
> >>>
> >>> Also, it looks like you've removed support for mam
On Aug 28, 2006, at 11:49 AM, Hollis Blanchard wrote:
On Mon, 2006-08-28 at 11:31 -0400, Jimi Xenidis wrote:
On Aug 28, 2006, at 10:50 AM, Hollis Blanchard wrote:
Also, it looks like you've removed support for mambo_memcpy(). I
don't
use Mambo *ahem* systemsim myself, but that seems wort
On Mon, 2006-08-28 at 11:31 -0400, Jimi Xenidis wrote:
> On Aug 28, 2006, at 10:50 AM, Hollis Blanchard wrote:
>
> >
> > Also, it looks like you've removed support for mambo_memcpy(). I don't
> > use Mambo *ahem* systemsim myself, but that seems worth keeping. I
> > guess
> > you could rename th
On Aug 28, 2006, at 10:50 AM, Hollis Blanchard wrote:
Also, it looks like you've removed support for mambo_memcpy(). I don't
use Mambo *ahem* systemsim myself, but that seems worth keeping. I
guess
you could rename the function while you're in there. :)
if we get these down to dcbz's then
On Fri, 2006-08-25 at 17:48 -0400, [EMAIL PROTECTED] wrote:
> +/* assumes destination page, *dp, is cacheable */
> +static __inline__ void copy_page_cacheable(void *dp, void *sp)
> +{
> + unsigned long dwords, dword_size;
> +
> + dword_size = 8;
> + dwords = (PAGE_SIZE / dword_siz
> Break how? build? run? hang?
Never mind - Turns-out to be an out-of-memory problem.
Booting goes all way to 'Waiting for /dev to be fully populated... '
then soon starts out-of-memory info, repeatedly. Had assumed it was
caused by something wrong in dcbz code. But when I added debug code
to
On Aug 25, 2006, at 5:48 PM, [EMAIL PROTECTED] wrote:
note2: in page_alloc.c, one of the three clear_page() calls breaks
the system
when changed to clear_page_cacheable().
I suspected why this was troubleseme, but I was wrong, can you give
us a reason why you think it is?
Off to the cod
On Aug 25, 2006, at 5:48 PM, [EMAIL PROTECTED] wrote:
Following code includes assembler versions of clear_page_cacheable
(), by Xenidis,
copy_page(), and copy_page_cacheable(). The 'cacheable' versions
use 'dcbz' for
clearing cache lines; the target page is assumed to be cacheable.
On Powe
Following code includes assembler versions of clear_page_cacheable(), by
Xenidis,
copy_page(), and copy_page_cacheable(). The 'cacheable' versions use 'dcbz' for
clearing cache lines; the target page is assumed to be cacheable.
This code has been debugged with a small application program on JS2
12 matches
Mail list logo
