[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0h7+53bT4oF109b-ah3wjFNYxz+PNr7DOBQ7rpRKbtGWQ@mail.gmail.com>
Date: Thu, 17 Oct 2019 21:20:01 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Zhenzhong Duan <zhenzhong.duan@...cle.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Linux PM <linux-pm@...r.kernel.org>,
Marcelo Tosatti <mtosatti@...hat.com>,
Joao Martins <joao.m.martins@...cle.com>
Subject: Re: [PATCH] cpuidle-haltpoll: make haltpoll aware of 'idle=' override
On Thu, Oct 17, 2019 at 2:41 AM Zhenzhong Duan
<zhenzhong.duan@...cle.com> wrote:
>
> Currenly haltpoll isn't aware of the 'idle=' override, the priority is
> 'idle=poll' > haltpoll > 'idle=halt'. When 'idle=poll' is used, cpuidle
> driver is bypassed but current_driver in sys still shows 'haltpoll'.
>
> When 'idle=halt' is used, haltpoll take precedence and make 'idle=halt'
> no effect.
>
> Add a check to not load haltpoll driver if there is 'idle='
OK
> and haltpoll
> is built in. If haltpoll is built as a module, still give a chance for
> admin to use it despite 'idle='.
Why exactly? Do you have any particular use case in mind?
Otherwise I'd prefer the behavior to be consistent regardless of
whether or not it is a module..
Powered by blists - more mailing lists