From: Jacek Luczak <difrost.kernel@gmail.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: pgtable_32.h - prototype and section mismatch fixes
Date: Mon, 14 Apr 2008 13:21:16 +0200 [thread overview]
Message-ID: <48033E2C.2080504@gmail.com> (raw)
In-Reply-To: <20080414095259.GA11966@uranus.ravnborg.org>
Sam Ravnborg pisze:
> On Mon, Apr 14, 2008 at 11:11:03AM +0200, Jacek Luczak wrote:
>> Sam Ravnborg pisze:
>>> On Mon, Apr 14, 2008 at 10:53:07AM +0200, Ingo Molnar wrote:
>>>> * Sam Ravnborg <sam@ravnborg.org> wrote:
>>>>
>>>>>> hm, that's an interesting case: we need those annotations probably
>>>>>> because gcc decided to not inline those functions. (this is possible
>>>>>> via the new CONFIG_OPTIMIZE_INLINING=y option) Sam, what's your take
>>>>>> on that?
>>>>> gcc uses different heuristics for inlining between the different
>>>>> versions. Therefore to achieve somehow predictable results I added
>>>>> -fno-inline-functions-called-once when CONFIG_DEBUG_SECTION_MISMATCH
>>>>> is enabled.
>>>>>
>>>>> So in the above case for any normal kernel build we would see that gcc
>>>>> inlined the above and everything is fine. But for the
>>>>> CONFIG_DEBUG_SECTION_MISMTCH cases we do not inline and thus we see
>>>>> that we have a section mismatch.
>>>> ah, ok. So i guess this will result in a few isolated cases of __init
>>>> annotations added to inline functions - Jacek fixed one such case - but
>>>> it should not result in the general spreading of __init annotations to
>>>> inline functions, correct? (which i was worried about)
>>> I do not think so. The need for small isolated inline functions
>>> in the init paths are minimal and last I did a section mismatch free
>>> sweep on the kernel it was only few if any inline functions(*) I had
>>> to annotate.
>>>
>>> (*) Considering only the minimal amount of function that ought
>>> to be annotated inlined.
>> There's a lot of inline __init functions already - which, on the other hand
>> should not result in more of such. Attached you can find grep on tree which
>> shows all inline __init functions (you won't find my paravirt_pagetable_setup_*
>> functions in output as I removed __init for test).
>
> Most of the functionas listed should never have been annotated inline.
> If you filter aways the functions that are in one one of their
> incarnations longer than 8 lines or are located in a .c file the list
> is much shorter. This is the real candidates (the figure '8' is just bad way
> to filter away 'complex' functions).
> Your paravirt_pagetable_setup_done is a real one btw.
It's worth of closer investigation I think.
>> Sam, do -fno-inline-functions-called-once could affect
>> paravirt_pagetable_setup_done? In general there was no section mismatch warning
>> for this function, but I've annotated it also.
> Most liekly yes - but I did not check.
GCC is ok, I mean it inlines paravirt_pagetable_setup_[start,done] even with
CONFIG_OPTIMIZE_INLINING=y:
$ objdump -t vmlinux.o | grep pagetable_setup_start
0000a418 g F .init.text 000000a1 native_pagetable_setup_start
While running with CONFIG_DEBUG_SECTION_MISMTCH=y it does not inline
paravirt_pagetable_setup_start (_done is OK):
$ objdump -t vmlinux.o | grep pagetable_setup_start
00017100 l F .text 0000000b paravirt_pagetable_setup_start
00009fb0 g F .init.text 00000089 native_pagetable_setup_start
DEBUG_SECTION_MISMATCH probably generated mismatch with smpboot_setup_io_apic()
(commit: 96c968742fa1e6d64f979464acf2fd90cdc117b3, already merged). I will check
and if __init is really superfluous I will post delta patch to remove all those
__init annotations.
Similar situation might be found with unlock_ExtINT_logic()
(arch/x86/kernel/io_apic_32.c), which I annotated with __init in one of previous
patches, but here, this function IMO shouldn't be marked inline.
-Jacek
next prev parent reply other threads:[~2008-04-14 11:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-13 15:41 [PATCH] x86: pgtable_32.h - prototype and section mismatch fixes Jacek Luczak
2008-04-14 7:26 ` Ingo Molnar
2008-04-14 8:41 ` Sam Ravnborg
2008-04-14 8:53 ` Ingo Molnar
2008-04-14 8:59 ` Sam Ravnborg
2008-04-14 9:11 ` Jacek Luczak
2008-04-14 9:52 ` Sam Ravnborg
2008-04-14 11:21 ` Jacek Luczak [this message]
2008-04-14 18:31 ` Sam Ravnborg
2008-04-14 8:59 ` Jacek Luczak
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=48033E2C.2080504@gmail.com \
--to=difrost.kernel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.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.