All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Thierry <jthierry@redhat.com>
To: peterz@infradead.org
Cc: linux-kernel@vger.kernel.org, jpoimboe@redhat.com,
	mhelsley@vmware.com, mbenes@suse.cz
Subject: Re: [PATCH v3 4/4] objtool: orc_gen: Move orc_entry out of instruction structure
Date: Thu, 30 Jul 2020 13:40:48 +0100	[thread overview]
Message-ID: <e4e239ad-120e-bd8f-4128-6976146c8512@redhat.com> (raw)
In-Reply-To: <20200730100304.GI2655@hirez.programming.kicks-ass.net>



On 7/30/20 11:03 AM, peterz@infradead.org wrote:
> On Thu, Jul 30, 2020 at 10:41:43AM +0100, Julien Thierry wrote:
>> One orc_entry is associated with each instruction in the object file,
>> but having the orc_entry contained by the instruction structure forces
>> architectures not implementing the orc subcommands to provide a dummy
>> definition of the orc_entry.
>>
>> Avoid that by having orc_entries in a separate list, part of the
>> objtool_file.
>>
> 
>> diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c
>> index 66fd56c33303..00f1efd05653 100644
>> --- a/tools/objtool/orc_gen.c
>> +++ b/tools/objtool/orc_gen.c
>> @@ -9,18 +9,33 @@
>>   #include "check.h"
>>   #include "warn.h"
>>   
>> +struct orc_data {
>> +	struct list_head list;
>> +	struct instruction *insn;
>> +	struct orc_entry orc;
>> +};
>> +
>>   int create_orc(struct objtool_file *file)
>>   {
>>   	struct instruction *insn;
>>   
>>   	for_each_insn(file, insn) {
>> -		struct orc_entry *orc = &insn->orc;
>>   		struct cfi_reg *cfa = &insn->cfi.cfa;
>>   		struct cfi_reg *bp = &insn->cfi.regs[CFI_BP];
>> +		struct orc_entry *orc;
>> +		struct orc_data *od;
>>   
>>   		if (!insn->sec->text)
>>   			continue;
>>   
>> +		od = calloc(1, sizeof(*od));
>> +		if (!od)
>> +			return -1;
>> +		od->insn = insn;
>> +		list_add_tail(&od->list, &file->orc_data_list);
>> +
>> +		orc = &od->orc;
>> +
>>   		orc->end = insn->cfi.end;
>>   
>>   		if (cfa->base == CFI_UNDEFINED) {
> 
> This will dramatically increase the amount of allocation calls, what, if
> anything, does this do for the performance of objtool?
> 

I guess I forgot about the usecase of running objtool on vmlinux...

On a kernel build for x86_64 defconfig, the difference in time seems to 
be withing the noise.

But I agree the proposed code is not ideal and on the other we've tried 
avoiding #ifdef in the code. Ideally I'd have an empty orc_entry 
definition when SUBCMD_ORC is not implemented.

Would you have a suggested approach to do that?

Thanks,

-- 
Julien Thierry


  reply	other threads:[~2020-07-30 12:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30  9:41 [PATCH v3 0/4] Remove dependency of check subcmd upon orc Julien Thierry
2020-07-30  9:41 ` [PATCH v3 1/4] objtool: Move object file loading out of check Julien Thierry
2020-07-30 14:09   ` Josh Poimboeuf
2020-07-30 14:42     ` Julien Thierry
2020-07-30  9:41 ` [PATCH v3 2/4] objtool: Move orc outside " Julien Thierry
2020-07-30  9:57   ` peterz
2020-07-30 12:40     ` Julien Thierry
2020-07-30 13:22       ` peterz
2020-07-30 13:29         ` Julien Thierry
2020-07-30 14:15           ` Josh Poimboeuf
2020-07-30 14:44             ` Julien Thierry
2020-07-31  7:56               ` Miroslav Benes
2020-07-31  8:19                 ` Julien Thierry
2020-07-30  9:41 ` [PATCH v3 3/4] objtool: orc: Skip setting orc_entry for non-text sections Julien Thierry
2020-07-30  9:41 ` [PATCH v3 4/4] objtool: orc_gen: Move orc_entry out of instruction structure Julien Thierry
2020-07-30 10:03   ` peterz
2020-07-30 12:40     ` Julien Thierry [this message]
2020-07-30 13:33       ` peterz
2020-07-30 13:45         ` Julien Thierry
2020-07-30 14:28           ` Josh Poimboeuf
2020-07-30 14:06 ` [PATCH v3 0/4] Remove dependency of check subcmd upon orc Josh Poimboeuf
2020-07-30 14:42   ` Julien Thierry
2020-07-30 15:05     ` Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e4e239ad-120e-bd8f-4128-6976146c8512@redhat.com \
    --to=jthierry@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mhelsley@vmware.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.