This is the mail archive of the
mailing list for the glibc project.
Re: Let's see if _this_ works...
Geoff Keating <firstname.lastname@example.org> writes:
> > > - 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.
Well, it's sort of hard not noticing the dynamic linker segfaulting
on every program... ;-)
> > 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?
Make a check on the first call to memset and cache the result in a
static variable like getpwd() does?
The problem is that Motorola seems to think that knowing what CPU
you're running on compromises system-security, so they made the PVR
only readble from supervisor mode...
The best I can think of is to export the PVR from kernel with the
sysctl interface (only a single syscall to read it as opposed to
a /proc file or similiar).
Marcus Sundberg | http://www.stacken.kth.se/~mackan/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: email@example.com