2023-05-12 08:57:28

by Amma Lee

[permalink] [raw]
Subject: [PATCH v2] riscv: optimize ELF relocation function in riscv

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 <[email protected]>
Reviewed-by: Conor Dooley <[email protected]>

---
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
+ * 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;
}
-
-
- for (j = 0; j < j_idx; j++){
+
+ /*
+ * If the last j-loop have been traversed to the
+ * maximum value but never match the
+ * corresponding symbol relocation item, the
+ * j-loop will execute the second loop which
+ * is begin from 0 to the prerious index (j_idx)
+ * unless the previous j_idx == 0;
+ */
+ for (j = 0; j < j_idx; j++) {
unsigned long hi20_loc =
sechdrs[sechdrs[relsec].sh_info].sh_addr
+ rel[j].r_offset;
u32 hi20_type = ELF_RISCV_R_TYPE(rel[j].r_info);
-
-
+
+
/* Find the corresponding HI20 relocation entry */
if (hi20_loc == sym->st_value
&& (hi20_type == R_RISCV_PCREL_HI20
@@ -447,36 +463,37 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
unsigned long hi20_sym_val =
hi20_sym->st_value
+ rel[j].r_addend;
-
-
+
+
/* Calculate lo12 */
size_t offset = hi20_sym_val - hi20_loc;
+ /* Calculate lo12 */
if (IS_ENABLED(CONFIG_MODULE_SECTIONS)
&& hi20_type == R_RISCV_GOT_HI20) {
offset = module_emit_got_entry(
me, hi20_sym_val);
offset = offset - hi20_loc;
-
+
}
hi20 = (offset + 0x800) & 0xfffff000;
lo12 = offset - hi20;
v = lo12;
-
+
break;
}
}
-
- if (j == j_idx)
- {
+
+ if (j == j_idx) {
pr_err(
"%s: Can not find HI20 relocation information\n",
me->name);
return -EINVAL;
}
-
-
+
+
}
-
+
+ /* Record the previous j-loop end index */
j_idx = j;
}

--
1.9.1



2023-05-12 09:12:34

by Conor Dooley

[permalink] [raw]
Subject: Re: [PATCH v2] riscv: optimize ELF relocation function in riscv

Hey Amma,

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 <[email protected]>

> Reviewed-by: Conor Dooley <[email protected]>

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 :(

>
> ---
> 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.

> + * 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,
Conor.


Attachments:
(No filename) (2.99 kB)
signature.asc (235.00 B)
Download all attachments

2023-05-12 10:16:54

by Andrew Jones

[permalink] [raw]
Subject: Re: [PATCH v2] riscv: optimize ELF relocation function in riscv

On Fri, May 12, 2023 at 12:04:13PM +0200, Andrew Jones wrote:
> 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 <[email protected]>
> > Reviewed-by: Conor Dooley <[email protected]>
> >
> > ---
> > 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*/
> > +
> > + /*
>
> whitespace issue here
>
> > + * In the second for-loops, each traversal for j is
> > + * 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;
> > }
> > -
> > -
> > - for (j = 0; j < j_idx; j++){
> > +
> > + /*
>
> also here
>
> > + * If the last j-loop have been traversed to the
> > + * maximum value but never match the
> > + * corresponding symbol relocation item, the
> > + * j-loop will execute the second loop which
> > + * is begin from 0 to the prerious index (j_idx)
>
> previous
>
> > + * unless the previous j_idx == 0;
> > + */
> > + for (j = 0; j < j_idx; j++) {
> > unsigned long hi20_loc =
> > sechdrs[sechdrs[relsec].sh_info].sh_addr
> > + rel[j].r_offset;
> > u32 hi20_type = ELF_RISCV_R_TYPE(rel[j].r_info);
> > -
> > -
> > +
> > +
>
> While fixing this whitespace, we could remove the redundant blank line too.
>
> > /* Find the corresponding HI20 relocation entry */
> > if (hi20_loc == sym->st_value
> > && (hi20_type == R_RISCV_PCREL_HI20
> > @@ -447,36 +463,37 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> > unsigned long hi20_sym_val =
> > hi20_sym->st_value
> > + rel[j].r_addend;
> > -
> > -
> > +
> > +
>
> also here
>
> > /* Calculate lo12 */
> > size_t offset = hi20_sym_val - hi20_loc;
> > + /* Calculate lo12 */
>
> stray copy+pasted line?
>
> > if (IS_ENABLED(CONFIG_MODULE_SECTIONS)
> > && hi20_type == R_RISCV_GOT_HI20) {
> > offset = module_emit_got_entry(
> > me, hi20_sym_val);
> > offset = offset - hi20_loc;
> > -
> > +
>
> need to just remove this blank line
>
> > }
> > hi20 = (offset + 0x800) & 0xfffff000;
> > lo12 = offset - hi20;
> > v = lo12;
> > -
> > +
>
> same here
>
> > break;
> > }
> > }
> > -
> > - if (j == j_idx)
> > - {
> > +
> > + if (j == j_idx) {
> > pr_err(
> > "%s: Can not find HI20 relocation information\n",
> > me->name);
> > return -EINVAL;
> > }
> > -
> > -
> > +
> > +
>
> should just remove both the blank lines above
>
> > }
> > -
> > +
> > + /* Record the previous j-loop end index */
> > j_idx = j;
>
> Huh... what did I miss? I went through the whole patch but only see
> formatting changes (and more opportunity for formatting changes).
> Where's the actual change?

It's best to do formatting ("no functional change") changes separately
from the functional changes to help reviewers see that, too. Please
separate the formatting into its own patch.

Thanks,
drew

2023-05-12 10:24:22

by Andrew Jones

[permalink] [raw]
Subject: Re: [PATCH v2] riscv: optimize ELF relocation function in riscv

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 <[email protected]>
> Reviewed-by: Conor Dooley <[email protected]>
>
> ---
> 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*/
> +
> + /*

whitespace issue here

> + * In the second for-loops, each traversal for j is
> + * 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;
> }
> -
> -
> - for (j = 0; j < j_idx; j++){
> +
> + /*

also here

> + * If the last j-loop have been traversed to the
> + * maximum value but never match the
> + * corresponding symbol relocation item, the
> + * j-loop will execute the second loop which
> + * is begin from 0 to the prerious index (j_idx)

previous

> + * unless the previous j_idx == 0;
> + */
> + for (j = 0; j < j_idx; j++) {
> unsigned long hi20_loc =
> sechdrs[sechdrs[relsec].sh_info].sh_addr
> + rel[j].r_offset;
> u32 hi20_type = ELF_RISCV_R_TYPE(rel[j].r_info);
> -
> -
> +
> +

While fixing this whitespace, we could remove the redundant blank line too.

> /* Find the corresponding HI20 relocation entry */
> if (hi20_loc == sym->st_value
> && (hi20_type == R_RISCV_PCREL_HI20
> @@ -447,36 +463,37 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> unsigned long hi20_sym_val =
> hi20_sym->st_value
> + rel[j].r_addend;
> -
> -
> +
> +

also here

> /* Calculate lo12 */
> size_t offset = hi20_sym_val - hi20_loc;
> + /* Calculate lo12 */

stray copy+pasted line?

> if (IS_ENABLED(CONFIG_MODULE_SECTIONS)
> && hi20_type == R_RISCV_GOT_HI20) {
> offset = module_emit_got_entry(
> me, hi20_sym_val);
> offset = offset - hi20_loc;
> -
> +

need to just remove this blank line

> }
> hi20 = (offset + 0x800) & 0xfffff000;
> lo12 = offset - hi20;
> v = lo12;
> -
> +

same here

> break;
> }
> }
> -
> - if (j == j_idx)
> - {
> +
> + if (j == j_idx) {
> pr_err(
> "%s: Can not find HI20 relocation information\n",
> me->name);
> return -EINVAL;
> }
> -
> -
> +
> +

should just remove both the blank lines above

> }
> -
> +
> + /* Record the previous j-loop end index */
> j_idx = j;

Huh... what did I miss? I went through the whole patch but only see
formatting changes (and more opportunity for formatting changes).
Where's the actual change?

Thanks,
drew