All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Andrew Morton <akpm@linux-foundation.org>,
	Christophe Leroy <christophe.leroy@c-s.fr>
Cc: linuxppc-dev@lists.ozlabs.org, Jason Baron <jbaron@akamai.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/10] powerpc: select DYNAMIC_DEBUG_RELATIVE_POINTERS for PPC64
Date: Wed, 24 Apr 2019 08:46:40 +0200	[thread overview]
Message-ID: <0fbffd5d-7e2a-1b12-5c94-b75f3f5d7ac1@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190423123611.1f7276cc4eb9f7a7005899a9@linux-foundation.org>

On 23/04/2019 21.36, Andrew Morton wrote:
> On Tue, 23 Apr 2019 17:37:33 +0200 Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> 
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -155,6 +155,7 @@ config PPC
>>>   	select BUILDTIME_EXTABLE_SORT
>>>   	select CLONE_BACKWARDS
>>>   	select DCACHE_WORD_ACCESS		if PPC64 && CPU_LITTLE_ENDIAN
>>> +	select DYNAMIC_DEBUG_RELATIVE_POINTERS	if PPC64
>>
>> Why only PPC64 ? Won't it work with PPC32 ? Or would it be 
>> counter-performant on 32 bits ?
> 
> Ditto arm and i386?
> 

It's pointless on 32-bit platforms - I'm replacing absolute const char*
pointers with a relative s32 offset from the _ddebug descriptor, so if
sizeof(void*)==4 there's no gain.

And yes, the current implementation also wouldn't work out-of-the-box
for 32-bit platforms, since the asm needs to know how to properly
initialize a whole struct _ddebug, which (often) contains a static_key,
which in turn contains a pointer member, which both affects its size as
well as its placement inside _ddebug. The C code in dynamic_debug.c
would likely Just Work, but there's no point in complicating the asm
part for no gain, so there are static_assert()s in place to ensure
BITS_PER_LONG==64 (as well as checking the various offsetof()s etc.).

[I don't think performance matters at all, it's one extra addition to
access these fields, and that is only done in the rare cases where
someone interacts with the dynamic_debug/control sysfs file, and when
one of the activated pr_debug()s is actually hit (so a few extra
instructions drown in the printk overhead).]

I do now see that PPC64 does not select GENERIC_BUG_RELATIVE_POINTERS,
so maybe this scheme simply doesn't work on PPC64, or nobody has done
the work to reduce the sizeof(struct bug_entry) on PPC64? As I said,
I've only compile-tested arm64 and ppc64.

Rasmus

WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Andrew Morton <akpm@linux-foundation.org>,
	Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Jason Baron <jbaron@akamai.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/10] powerpc: select DYNAMIC_DEBUG_RELATIVE_POINTERS for PPC64
Date: Wed, 24 Apr 2019 08:46:40 +0200	[thread overview]
Message-ID: <0fbffd5d-7e2a-1b12-5c94-b75f3f5d7ac1@rasmusvillemoes.dk> (raw)
In-Reply-To: <20190423123611.1f7276cc4eb9f7a7005899a9@linux-foundation.org>

On 23/04/2019 21.36, Andrew Morton wrote:
> On Tue, 23 Apr 2019 17:37:33 +0200 Christophe Leroy <christophe.leroy@c-s.fr> wrote:
> 
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -155,6 +155,7 @@ config PPC
>>>   	select BUILDTIME_EXTABLE_SORT
>>>   	select CLONE_BACKWARDS
>>>   	select DCACHE_WORD_ACCESS		if PPC64 && CPU_LITTLE_ENDIAN
>>> +	select DYNAMIC_DEBUG_RELATIVE_POINTERS	if PPC64
>>
>> Why only PPC64 ? Won't it work with PPC32 ? Or would it be 
>> counter-performant on 32 bits ?
> 
> Ditto arm and i386?
> 

It's pointless on 32-bit platforms - I'm replacing absolute const char*
pointers with a relative s32 offset from the _ddebug descriptor, so if
sizeof(void*)==4 there's no gain.

And yes, the current implementation also wouldn't work out-of-the-box
for 32-bit platforms, since the asm needs to know how to properly
initialize a whole struct _ddebug, which (often) contains a static_key,
which in turn contains a pointer member, which both affects its size as
well as its placement inside _ddebug. The C code in dynamic_debug.c
would likely Just Work, but there's no point in complicating the asm
part for no gain, so there are static_assert()s in place to ensure
BITS_PER_LONG==64 (as well as checking the various offsetof()s etc.).

[I don't think performance matters at all, it's one extra addition to
access these fields, and that is only done in the rare cases where
someone interacts with the dynamic_debug/control sysfs file, and when
one of the activated pr_debug()s is actually hit (so a few extra
instructions drown in the printk overhead).]

I do now see that PPC64 does not select GENERIC_BUG_RELATIVE_POINTERS,
so maybe this scheme simply doesn't work on PPC64, or nobody has done
the work to reduce the sizeof(struct bug_entry) on PPC64? As I said,
I've only compile-tested arm64 and ppc64.

Rasmus

  reply	other threads:[~2019-04-24  6:46 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 21:25 [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS Rasmus Villemoes
2019-04-09 21:25 ` Rasmus Villemoes
2019-04-09 21:25 ` Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 01/10] linux/device.h: use unique identifier for each struct _ddebug Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 02/10] linux/net.h: " Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 03/10] linux/printk.h: " Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 04/10] dynamic_debug: introduce accessors for string members of " Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 05/10] dynamic_debug: drop use of bitfields in " Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 06/10] dynamic_debug: introduce CONFIG_DYNAMIC_DEBUG_RELATIVE_POINTERS Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 07/10] dynamic_debug: add asm-generic implementation for DYNAMIC_DEBUG_RELATIVE_POINTERS Rasmus Villemoes
2019-04-09 21:25   ` Rasmus Villemoes
2019-04-09 21:25   ` Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 08/10] x86-64: select DYNAMIC_DEBUG_RELATIVE_POINTERS Rasmus Villemoes
2019-04-10  7:31   ` Ingo Molnar
2019-04-09 21:25 ` [PATCH 09/10] arm64: " Rasmus Villemoes
2019-04-09 21:25   ` Rasmus Villemoes
2019-04-26  9:39   ` Arnd Bergmann
2019-04-26  9:39     ` Arnd Bergmann
2019-04-26 10:05     ` Rasmus Villemoes
2019-04-26 10:05       ` Rasmus Villemoes
2019-04-26 13:00       ` Nathan Chancellor
2019-04-26 13:00         ` Nathan Chancellor
2019-04-26 19:06         ` [PATCH 11/10] arm64: unbreak DYNAMIC_DEBUG=y build with clang Rasmus Villemoes
2019-04-26 19:06           ` Rasmus Villemoes
2019-04-26 19:06           ` [PATCH 12/10] powerpc: " Rasmus Villemoes
2019-04-26 19:06             ` Rasmus Villemoes
2019-04-29 17:34             ` Nick Desaulniers
2019-04-29 17:34               ` Nick Desaulniers
2019-04-26 19:27           ` [PATCH 11/10] arm64: " Rasmus Villemoes
2019-04-26 19:27             ` Rasmus Villemoes
2019-04-26 21:58             ` Konstantin Ryabitsev
2019-04-26 21:58               ` Konstantin Ryabitsev
2019-04-26 22:07             ` Konstantin Ryabitsev
2019-04-26 22:07               ` Konstantin Ryabitsev
2019-04-29 17:32           ` Nick Desaulniers
2019-04-29 17:32             ` Nick Desaulniers
2019-04-30 18:22             ` Nick Desaulniers
2019-04-30 18:22               ` Nick Desaulniers
2019-05-02  8:57               ` Rasmus Villemoes
2019-05-02  8:57                 ` Rasmus Villemoes
2019-04-09 21:25 ` [PATCH 10/10] powerpc: select DYNAMIC_DEBUG_RELATIVE_POINTERS for PPC64 Rasmus Villemoes
2019-04-09 21:25   ` Rasmus Villemoes
2019-04-23 15:37   ` Christophe Leroy
2019-04-23 19:36     ` Andrew Morton
2019-04-23 19:36       ` Andrew Morton
2019-04-24  6:46       ` Rasmus Villemoes [this message]
2019-04-24  6:46         ` Rasmus Villemoes
2019-05-06  6:48 ` [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS Rasmus Villemoes
2019-05-06  6:48   ` Rasmus Villemoes
2019-05-06  6:48   ` Rasmus Villemoes
2019-05-06  7:05   ` Ingo Molnar
2019-05-06  7:05     ` Ingo Molnar
2019-05-06  7:05     ` Ingo Molnar
2019-05-06  7:34     ` Rasmus Villemoes
2019-05-06  7:34       ` Rasmus Villemoes
2019-05-06  7:34       ` Rasmus Villemoes
2019-05-06  7:48       ` Ingo Molnar
2019-05-06  7:48         ` Ingo Molnar
2019-05-06  7:48         ` Ingo Molnar
2019-05-06 14:48       ` Segher Boessenkool
2019-05-06 14:48         ` Segher Boessenkool
2019-05-06 14:48         ` Segher Boessenkool

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=0fbffd5d-7e2a-1b12-5c94-b75f3f5d7ac1@rasmusvillemoes.dk \
    --to=linux@rasmusvillemoes.dk \
    --cc=akpm@linux-foundation.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=jbaron@akamai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.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.