[PATCH] [POWERPC] Optimize counting distinct entries in therelocation sections

Medve Emilian Emilian.Medve at freescale.com
Tue Nov 13 09:31:53 EST 2007


Hello Paul,


> > Actually I notice that count_relocs is counting all relocs, not just
> > the R_PPC_REL24 ones, which are all that we actually care about in
> > sizing the PLT.  And I would be willing to bet that every single
> > R_PPC_REL24 reloc has r_addend == 0.
> 
> I'll count only the R_PPC_REL24 and I'll validate if they 
> have r_addend
> == 0.

Seems like there are R_PPC_REL24 with r_addend != 0. Within a set of 41
modules (featuring 5457 R_PPC_REL24 relocations) already included within
the kernel tree I found 37 such relocations (R_PPC_REL24) with r_addend
!= 0. In my test case, from 35K relocations, 7K are R_PPC_REL24 and from
those only 8 have r_addend != 0.

> > Also I notice that even with your patch, the actual process of doing
> > the relocations will take time proportional to the product of the
> > number of PLT entries times the number of R_PPC_REL24 relocations,
> > since we do a linear search through the PLT entries each time.
> 
> The reason I started working on this patch was because the kernel
> detected a soft lockup in count_relocs(). It didn't complain 
> about other
> parts so I did nothing about them.

Since the time hog in my case (and other's cases, reflected by the
previous patches) seems to be count_relocs(), would it be acceptable as
an incremental improvement to fix this now and address the relocation
process performance (later) if needed?

I'll resubmit the patch incorporating some of the feedback from you and
Rusty.


Cheers,
Emil.



More information about the Linuxppc-dev mailing list