From: Daniel Borkmann <dborkman@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Joe Mario <jmario@redhat.com>
Subject: Re: [PATCH akpm/next] lib: crc32: conditionally constify crc32 lookup table
Date: Sat, 03 Jan 2015 01:12:43 +0100 [thread overview]
Message-ID: <54A733FB.8010904@redhat.com> (raw)
In-Reply-To: <20150102153537.2251ca287e96446eaf229ae2@linux-foundation.org>
On 01/03/2015 12:35 AM, Andrew Morton wrote:
> On Wed, 31 Dec 2014 20:03:28 +0100 Daniel Borkmann <dborkman@redhat.com> wrote:
>
>> Commit 8f243af42ade ("sections: fix const sections for crc32 table")
>
> The 8f243af42ade changelog is rather poor :(. With the help of this
> changelog I can now see what 8f243af42ade was doing. I must have been
> asleep at the time.
>
>> removed the compile-time generated crc32 tables from the RO sections,
>> because it conflicts with the definition of __cacheline_aligned
>> which puts all such aligned data into .data..cacheline_aligned section
>> optimized for wasting less space, and causes const align issues with
>> some GCC versions (see #52181, for example).
>
> (searches several bugzilla databases)
>
> "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52181" would be more
> reader-friendly.
Okay, will add it like that.
>> We can fix that in two steps: 1) by using the ____cacheline_aligned
>> version, which only aligns the data but doesn't move it into specific
>> sections, 2) test GCC and in problematic cases fall back to the current
>> code, otherwise use const and proper alignment for the lookup tables.
>>
>> After patch tables are in RO:
>>
>> $ nm -v lib/crc32.o | grep -1 -E "crc32c?table"
>> 0000000000000000 t arch_local_irq_enable
>> 0000000000000000 r crc32ctable_le
>> 0000000000000000 t crc32_exit
>> --
>> 0000000000000960 t test_buf
>> 0000000000002000 r crc32table_be
>> 0000000000004000 r crc32table_le
>> 000000001d1056e5 A __crc_crc32_be
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
>> Cc: Joe Mario <jmario@redhat.com>
>> ---
>> Makefile | 5 +++++
>> lib/Makefile | 3 +++
>> lib/gen_crc32table.c | 21 +++++++++++++++------
>> scripts/gcc-const-align.sh | 21 +++++++++++++++++++++
>> 4 files changed, 44 insertions(+), 6 deletions(-)
>
> Seems a lot of fuss. Why are these tables cacheline aligned anyway?
> To avoid one cache miss (most of the time, presumably) in a 16k table.
> Pretty marginal benefit, I suspect.
I guess, it actually came in with the slice-by-8 algorithm (e.g. used
in SCTP checksumming if no offloading is available) that was added back
then, that is, commit 324eb0f17d9dc ("crc32: add slice-by-8 algorithm
to existing code").
>> --- a/lib/Makefile
>> +++ b/lib/Makefile
>> @@ -171,6 +171,9 @@ obj-$(CONFIG_FONT_SUPPORT) += fonts/
>> hostprogs-y := gen_crc32table
>> clean-files := crc32table.h
>>
>> +# We need to transfer this flag to the host compiler if present
>> +HOSTCFLAGS_gen_crc32table.o := $(findstring -DCC_HAVE_CONST_ALIGN,$(KBUILD_CFLAGS))
>> +
>> $(obj)/crc32.o: $(obj)/crc32table.h
>>
>> quiet_cmd_crc32 = GEN $@
>> diff --git a/lib/gen_crc32table.c b/lib/gen_crc32table.c
>> index 71fcfcd..2f06893 100644
>> --- a/lib/gen_crc32table.c
>> +++ b/lib/gen_crc32table.c
>> @@ -21,6 +21,14 @@
>> # define BE_TABLE_SIZE (1 << CRC_BE_BITS)
>> #endif
>>
>> +#ifdef CC_HAVE_CONST_ALIGN
>> +# define TABLE_CONST_ATTR "const"
>> +# define TABLE_ALIGNMENT "____cacheline_aligned"
>> +#else
>> +# define TABLE_CONST_ATTR ""
>> +# define TABLE_ALIGNMENT "__cacheline_aligned"
>> +#endif
>
> Pity out poor readers, trying to work out what all this does and why it
> is here. It is totally unobvious that this is working around some gcc
> bug. Can we please have a nice comment which explains everything?
Will add a comment, sure.
Thanks, Andrew!
I'll send out v2 with your feedback tomorrow.
next prev parent reply other threads:[~2015-01-03 0:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 19:03 [PATCH akpm/next] lib: crc32: conditionally constify crc32 lookup table Daniel Borkmann
2015-01-02 23:35 ` Andrew Morton
2015-01-03 0:12 ` Daniel Borkmann [this message]
2015-01-03 1:08 ` Andrew Morton
2015-01-03 9:34 ` Daniel Borkmann
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=54A733FB.8010904@redhat.com \
--to=dborkman@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jmario@redhat.com \
--cc=linux-kernel@vger.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 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.