回复:[PATCH v2] riscv: optimize ELF relocation function in riscv

Conor Dooley conor.dooley at microchip.com
Mon May 15 04:50:13 PDT 2023


On Mon, May 15, 2023 at 05:58:35PM +0800, 李筱云(李筱云) wrote:
> Hi Conor,
> 
> On Fri, May 12, 2023 at 04:51:53PM +0800, Amma Lee wrote:
> >> The patch can optimize the running times of "insmod" command by modify ELF
> >> relocation function.
> >> When install the riscv ELF driver which contains multiple
> >> symbol table items to be relocated, kernel takes a lot of time to
> >> execute the relocation. For example, we install a 3+MB driver need 180+s.
> >> We focus on the riscv kernel handle R_RISCV_HI20 and R_RISCV_LO12 type
> >> items relocation function and find that there are two for-loops in this
> >> function. If we modify the begin number in the second for-loops iteration,
> >> we could save significant time for installation. We install the 3+MB
> >> driver could just need 2s.
> >>
> >> Signed-off-by: Amma Lee <lixiaoyun at binary-semi.com>
> >> Reviewed-by: Conor Dooley <conor at kernel.org>
> 
> >I did not provide this tag. Do not add tags that you were not explicitly
> >given by people.
> >
> >Also, you didn't actually even implement all of the things I pointed out
> >either :(
> 
> I'm sorry. I will delete the "Reviewed-by" line. And in the patch v2, I
> changed the name as "Amma Lee" and add some comments before the
> modified code. Is there other content I need to modify?

Perhaps, I have not examined the actual implementation here.
Hopefully someone that understands the code better will do that.
I was mainly pointing out low-hanging items that our automation caught.


> >> ---
> >>  arch/riscv/kernel/module.c | 53 ++++++++++++++++++++++++++++++----------------
> >>  1 file changed, 35 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
> >> index 55507b0..1683c1d 100755
> >> --- a/arch/riscv/kernel/module.c
> >> +++ b/arch/riscv/kernel/module.c
> >> @@ -385,9 +385,17 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> >>
> >>    if (type == R_RISCV_PCREL_LO12_I || type == R_RISCV_PCREL_LO12_S) {
> >>     unsigned int j;
> >> -   /*Modify the j for-loops begin number from last iterates end value*/
> >> +
> >> +   /*
> >> +   * In the second for-loops, each traversal for j is
> >                        ^^
> >Comment in passing here, we align the *s in comments.
> 
> Do you mean that there is no blank in '*' and the key?

In my plaintext editor, the ^^ was aligned with the *.
Please read the kernel coding style documentation for more information:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting

> >> +   * starts from 0 to the symbol table item index which
> >> +   * is detected. By the tool "readelf", we find that all
> >> +   * the symbol table items about R_RISCV_PCREL_HI20 type
> >> +   * are incrementally added in order. It means that we
> >> +   * could interate the j with the previous loop end
> >> +   * value(j_idx) as the begin number in the next loop;
> >> +   */
> >>     for (j = j_idx; j < sechdrs[relsec].sh_size / sizeof(*rel); j++) {
> >> -   /* Modify end */
> >>      unsigned long hi20_loc =
> >>       sechdrs[sechdrs[relsec].sh_info].sh_addr
> >>       + rel[j].r_offset;
> >> @@ -420,22 +428,30 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> >>       break;
> >>      }
> >>     }
> >> +
> >>     if (j == sechdrs[relsec].sh_size / sizeof(*rel)) {
> >> -    if(j_idx == 0){
> >> +    if (j_idx == 0) {
> >>       pr_err(
> >>        "%s: Can not find HI20 relocation information\n",
> >>        me->name);
> >>       return -EINVAL;
> >>      }
> >> -
> >> -
> >
> >^^ and this is one of the checkpatch complaints I mentioned last time,
> >no double blank lines please.
> >
> >Also, this version of the patch doesn't actually apply for me to
> >v6.4-rc1 anymore, but the file has not been modified in upstream since
> >29/01. Not too sure what you have used as the base for this as a result
> >:/
> Thanks, I will delete the double blank lines. We found and fix the issue -
> insmod drivers operation takes a lot time which contains multiple symbol
> items to be relocated in the kernel version 5.10. Then we compare the
> 6.4 new code and 5.10 kernel, find the insmod process(5.10 version in
> the kernel\module.c and arch\riscv\kernel\module.c, 6.4 version
> in the kernel\module\main.c and arch\riscv\kernel\module.c) never be
> changed. So we guess that the kernel version 6.4 has the same issue.
> May I commit the patch in 6.4 kernel?

In fact, you *must* do your development against the 6.4 version of the
kernel. If you want to fix it for 5.10, you must first either:
a) fix the problem in 6.4, or
b) show that there is not a problem in 6.4 & figure out where it was
   introduced

The stable maintainers won't take the fix for 5.10 unless it is already
in mainline or not a problem in mainline.

Also, this email was in html form. Please don't send html mail to the
mailing list. I had to jump through some hoops to be even able to reply
to it on my current setup :(

Thanks,
Conor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20230515/e6a652eb/attachment.sig>


More information about the linux-riscv mailing list