This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Let's see if _this_ works...


Geoff Keating <geoffk@ozemail.com.au> 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
> '8'.

Ok, fine.

> 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
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]