[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKohponUigqKOkj3i2=LDgVG0bi4dXsbrJCDpzv6M3k1E_Y6Ew@mail.gmail.com>
Date: Mon, 15 Oct 2012 14:11:53 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Michal Hocko <mhocko@...e.cz>
Cc: rjw@...k.pl, tglx@...utronix.de, cpufreq@...r.kernel.org,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
linaro-dev@...ts.linaro.org, patches@...aro.org,
Robin.Randhawa@....com
Subject: Re: [PATCH] cpufreq: timer: Move tick-sched specific code outside of
cpufreq governors
On 15 October 2012 14:05, Michal Hocko <mhocko@...e.cz> wrote:
> On Mon 15-10-12 13:41:20, Viresh Kumar wrote:
>> Multiple cpufreq governers have defined similar get_cpu_idle_time_***()
>> routines. These routines must be moved to some common place, so that all
>> governors can use them.
>>
>> So moving them to tick-sched.c, which seems to be a better place for keeping
>> these routines.
>
> I do agree that this code duplication should be removed but tick-sched.c
> is not a right place IMO. Who, apart from governors, should use those
> "common" functions?
Nobody leaving cpufreq for now.
> Having a generic get_cpu_idle_time, which in fact includes iowait time
> as well is definitely not good. It is confusing and it doesn't match
> get_cpu_idle_time_us.
ok
> I would suggest moving the common functionality into drivers/cpufreq/
> (e.g. cpufreq_common.c).
Initially i did that only, but then thought these routines must be present in
more generic files if possible, available across frameworks.
Can we try renaming these to show there exact functionality and then put
them in generic files like, tick-sched.c?
--
viresh
--
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