From: Helge Deller <deller@gmx.de>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: deller@kernel.org, linux-kernel@vger.kernel.org,
Masahiro Yamada <masahiroy@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
linux-modules@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH 2/4] modules: Ensure 64-bit alignment on __ksymtab_* sections
Date: Mon, 22 Jan 2024 17:47:49 +0100 [thread overview]
Message-ID: <b5e98501-6262-4b04-bbae-238e4956f904@gmx.de> (raw)
In-Reply-To: <Za6Td6cx3JbTfnCZ@bombadil.infradead.org>
On 1/22/24 17:10, Luis Chamberlain wrote:
> On Sat, Dec 30, 2023 at 08:33:24AM +0100, Helge Deller wrote:
>> Your selftest code is based on perf.
>> AFAICS we don't have perf on parisc/hppa,
>
> I see!
>
>> so I can't test your selftest code
>> on that architecture.
>> I assume you tested on x86, where the CPU will transparently take care of
>> unaligned accesses. This is probably why the results are within
>> the noise.
>> But on some platforms the CPU raises an exception on unaligned accesses
>> and jumps into special exception handler assembler code inside the kernel.
>> This is much more expensive than on x86, which is why we track on parisc
>> in /proc/cpuinfo counters on how often this exception handler is called:
>> IRQ: CPU0 CPU1
>> 3: 1332 0 SuperIO ttyS0
>> 7: 1270013 0 SuperIO pata_ns87415
>> 64: 320023012 320021431 CPU timer
>> 65: 17080507 20624423 CPU IPI
>> UAH: 10948640 58104 Unaligned access handler traps
>>
>> This "UAH" field could theoretically be used to extend your selftest.
>
> Nice!
>
>> But is it really worth it? The outcome is very much architecture and CPU
>> specific, maybe it's just within the noise as you measured.
>
> It's within the noise for x86_64, but given what you suggest
> for parisc where it is much more expensive, we should see a non-noise
> delta. Even just time on loading the module should likely result in
> a considerable delta than on x86_64. You may just need to play a bit
> with the default values at build time.
I don't know if it will be a "considerable" amount of time.
>> IMHO we should always try to natively align structures, and if we see
>> we got it wrong in kernel code, we should fix it.
>
> This was all motivated by the first review criteria of these patches
> as if they were stable worthy or not. Even if we don't consider them
> stable material, given the test is now written and easily extended to
> test on parisc with just timing information and UAH I think it would
> be nice to have this data for a few larger default factor values so we
> can compare against x86_64 while we're at it.
>
> If you don't feel like doing that test that's fine too, we can just
> ignore that.
I can do that test, but I won't have time for that in the next few weeks...
> I'll still apply the patches
Yes, please do!
Even if I don't test now, I (or others) will test at a later point.
> but, I figured I'd ask to collect information while the test was already
> written and it should now be easy to compare / contrast differences.
Ok.
Helge
next prev parent reply other threads:[~2024-01-22 16:47 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 22:18 [PATCH 0/4] Section alignment issues? deller
2023-11-22 22:18 ` [PATCH 1/4] linux/export: Fix alignment for 64-bit ksymtab entries deller
2023-12-21 10:22 ` Masahiro Yamada
2023-12-21 16:01 ` Masahiro Yamada
2023-12-22 6:07 ` Luis Chamberlain
2023-12-22 6:08 ` Luis Chamberlain
2023-12-22 7:01 ` Masahiro Yamada
2023-12-22 20:11 ` Luis Chamberlain
2023-12-23 14:35 ` Masahiro Yamada
2023-11-22 22:18 ` [PATCH 2/4] modules: Ensure 64-bit alignment on __ksymtab_* sections deller
2023-12-22 5:59 ` Luis Chamberlain
2023-12-22 12:13 ` Helge Deller
2023-12-22 20:10 ` Luis Chamberlain
2023-12-30 7:33 ` Helge Deller
2024-01-22 16:10 ` Luis Chamberlain
2024-01-22 16:47 ` Helge Deller [this message]
2024-01-22 18:48 ` Luis Chamberlain
2023-11-22 22:18 ` [PATCH 3/4] vmlinux.lds.h: Fix alignment for __ksymtab*, __kcrctab_* and .pci_fixup sections deller
2023-12-21 13:07 ` Masahiro Yamada
2023-12-22 9:02 ` Helge Deller
2023-12-23 4:10 ` Masahiro Yamada
2023-11-22 22:18 ` [PATCH 4/4] modules: Add missing entry for __ex_table deller
2024-01-29 18:50 ` Luis Chamberlain
2023-12-19 21:26 ` [PATCH 0/4] Section alignment issues? Luis Chamberlain
2023-12-20 19:40 ` Luis Chamberlain
2023-12-22 9:13 ` Helge Deller
2023-12-21 13:40 ` Masahiro Yamada
2023-12-21 15:42 ` Masahiro Yamada
2023-12-22 8:23 ` Helge Deller
2023-12-23 1:32 ` Masahiro Yamada
2023-12-22 9:48 ` David Laight
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=b5e98501-6262-4b04-bbae-238e4956f904@gmx.de \
--to=deller@gmx.de \
--cc=arnd@arndb.de \
--cc=deller@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).