[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <564D9605.4010207@sigmadesigns.com>
Date: Thu, 19 Nov 2015 10:27:33 +0100
From: Marc Gonzalez <marc_gonzalez@...madesigns.com>
To: Russell King - ARM Linux <linux@....linux.org.uk>
CC: Thomas Gleixner <tglx@...utronix.de>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
LKML <linux-kernel@...r.kernel.org>,
Mans Rullgard <mans@...sr.com>,
Viresh Kumar <viresh.kumar@...aro.org>,
Nicolas Pitre <nico@...aro.org>,
Tony Lindgren <tony@...mide.com>,
Sebastian Frias <sebastian_frias@...madesigns.com>
Subject: Re: [PATCH] clocksource: Store reg field within struct clocksource
On 18/11/2015 18:21, Russell King - ARM Linux wrote:
> On Wed, Nov 18, 2015 at 02:43:34PM +0100, Marc Gonzalez wrote:
>
>> Since 'struct clocksource' is ____cacheline_aligned, gcc must insert
>> a lot of padding between reg and clksrc in 'struct clocksource_mmio'
>> (for example, L1_CACHE_BYTES = 64 on ARMv7).
>>
>> Storing reg within 'struct clocksource' removes unnecessary padding,
>> and reg can then be grouped with other hot data. A nice side-effect
>> of this patch is making container_of() unnecessary, which makes the
>> code a bit simpler.
>>
>> On 32-bit platforms, reg fits in the padding between read and mask,
>> meaning no downside from storing it there.
>
> Just swap the order of 'reg' and 'clksrc'.
You already suggested that the last time (April 1st).
What problem is this supposed to solve?
Swapping the fields does not change the amount of padding required,
and does not place reg close to the hot data.
On a 32-bit platform, with L1_CACHE_BYTES = 64
sizeof(struct unaligned_clocksource) = 80
sizeof(struct clocksource) = 128
sizeof(struct clocksource_mmio) = 192, reg at +0, clksrc at +64
sizeof(struct clocksource_mmio2) = 192, reg at +128, clksrc at +0
Same amount of padding.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists