[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151119110842.GX8644@n2100.arm.linux.org.uk>
Date: Thu, 19 Nov 2015 11:08:42 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Marc Gonzalez <marc_gonzalez@...madesigns.com>,
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 Thu, Nov 19, 2015 at 11:42:48AM +0100, Thomas Gleixner wrote:
> On Thu, 19 Nov 2015, Russell King - ARM Linux wrote:
> > The basic cause of this problem is the ____cacheline_aligned annotation
> > which effectively prevents wrapping struct clocksource to provide
> > implementation specific data.
> >
> > Maybe your idea is that struct clocksource should be bloated with all
> > implementation specific data in the long term?
>
> Certainly not. That mmio use case is sane enough, but you are right,
> that we should try to lift that ____cacheline_aligned restriction.
I don't think the cache line alignment of struct clocksource matters
anymore - the core timekeeping code no longer uses struct clocksource
but instead uses struct timekeeper, which caches much of the data from
struct clocksource. The only member of struct clocksource which it
does access is max_cycles, which is more than 32 bytes into struct
clocksource.
So, I see no reason to waste memory with all these struct clocksources
being bloated out to cacheline alignments. In addition, once
____cacheline_aligned is removed, I see no reason for Marc's change
either.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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