[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=XbcAUgcSm-E4ktys+pDzL9+BKqdC4zjgKS4C-QhLA-9Q@mail.gmail.com>
Date: Tue, 13 May 2014 15:54:16 -0700
From: Doug Anderson <dianders@...omium.org>
To: Paul Gortmaker <paul.gortmaker@...driver.com>,
John Stultz <john.stultz@...aro.org>
Cc: David Riley <davidriley@...omium.org>,
Will Deacon <Will.Deacon@....com>,
Olof Johansson <olof@...om.net>,
Sonny Rao <sonnyrao@...omium.org>,
Russell King <linux@....linux.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] init: Don't decrease loops_per_jiffy when a CPU comes up
Paul,
On Fri, May 9, 2014 at 9:03 AM, Paul Gortmaker
<paul.gortmaker@...driver.com> wrote:
> On 14-05-07 07:50 PM, Doug Anderson wrote:
>> The loops_per_jiffy count continues to be updated as each CPU is
>> brought up. This causes problems when we've got an HMP system and
>> different CPUs have different loops per jiffy. On exynos 542x
>> systems, for instance, the A7s will have significantly lower loops per
>> jiffy than their big brothers.
>
> Based on the other discussion for the ARM variant of this, I'm
> assuming this also becomes a WFC issue. And if not, then it
> probably should go by John or similar ; getmaintainers is just
> being dumb in spitting my name out, since I only made one
> trivial change to this file a year ago or similar.
I think this change could still make sense. The ARM discussion is
about dealing with the scaling that the ARM code does, but it really
is a separate concept.
In general it seems like at least a warning is in order if
loops_per_jiffy changes significantly from CPU to CPU.
--
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