This is the mail archive of the
mailing list for the glibc project.
Re: Let's see if _this_ works...
> Cc: firstname.lastname@example.org
> From: Marcus Sundberg <email@example.com>
> Date: 24 Nov 1999 17:16:24 +0100
> User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.3
> Geoff Keating <firstname.lastname@example.org> writes:
> This is not really about the patch, but relevant for dl-machine.c
> regardless of whether this patch is applied or not.
> > --- libc/sysdeps/powerpc/dl-machine.c.p56b Thu Oct 7 21:12:54 1999
> > +++ libc/sysdeps/powerpc/dl-machine.c Mon Nov 15 17:48:11 1999
> > @@ -136,126 +143,172 @@ __elf_preferred_address(struct link_map
> > Assumes the cache line size is at least 32 bytes, or at least
> > - that dcbst and icbi apply to 32-byte lines. At present, all
> > + that dcbst and icbi apply to 32-byte lines. At present, all
> > PowerPC processors have line sizes of exactly 32 bytes. */
> This is not true. The Motorola 8xx series of processors have a
> line size of 16 bytes.
Grrr. They shouldn't do that.
> > - size_modified = lazy ? rel_offset_words : PLT_INITIAL_ENTRY_WORDS;
> > - for (i = 0; i < size_modified; i+= 8)
> > + size_modified = lazy ? rel_offset_words : 6;
> > + for (i = 0; i < size_modified; i += 8)
> > PPC_DCBST (plt + i);
> How performance critical is this code? Would changing 8 ==> 4 affect
> performance at all? (the bottleneck should be pushing the data to the
> L2 cache or RAM anyway, not executing the loop, right?)
> Or will this have to be a compile-time option (bad)?
I think that if you do a dcbst on a block which is not modified in the
cache, it'll be much faster. So it'd probably be OK to change the
Note that this has been assuming this line size since I wrote it---if
you haven't noticed any problems, you can safely say that the 8xx do
have a 32-bit (or more) line size.
Annoyingly, the PowerPC architecture explicitly says that it is
undefined what size cache lines are.
> Then there is the issue of memset.S, which also assumes a cache line
> size of 32 bytes. Currently I simply move it away when I build glibc,
> but it would be nice if that could be solved as well. Now that there
> is FP-emulation for PPC in the kernel the cache line issue is the
> only thing preventing the same glibc binary from running on 8xx and
> other PPC cpus.
I really don't want to halve the speed of bzero() for all machines.
Any other ideas?
Geoffrey Keating <email@example.com>