All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dirk Brandewie <dirk.brandewie@gmail.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
	Dirk Brandewie <dirk.brandewie@gmail.com>
Cc: dirk.j.brandewie@intel.com,
	"Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Patrick Marlier <patrick.marlier@gmail.com>
Subject: Re: [PATCH v2 2/2] intel_pstate: Set core to min P state during core offline
Date: Wed, 19 Mar 2014 08:32:03 -0700	[thread overview]
Message-ID: <5329B873.7070100@intel.com> (raw)
In-Reply-To: <CAKohpomM5s0v+442Pyg2HFguJs3tXKTNWFnHCfJmRJpTPvY=3A@mail.gmail.com>

On 03/18/2014 10:20 PM, Viresh Kumar wrote:
> On 19 March 2014 01:14, Dirk Brandewie <dirk.brandewie@gmail.com> wrote:
>> There was no problem per se.  In stop() all I really needed to do is stop
>> the
>> timer and set the P state to MIN.
>>
>> At init time I need to allocate memory and start timer.  If stopping the
>> timer
>> and deallocating memory are separated then I need code in init() to detect
>> this case.
>
> Sorry, I didn't understood what exactly is special here :(
>
> If we return failure from CPU_POST_DEAD for some reason without
> calling exit() then you will have memory leak in your init() as we are
> allocating memory without checking if we already have that (nothing wrong
> in it though as other parts of kernel should handle things properly here).

No.  If you got the CPU_POST_DEAD callback CPU_DOWN_PREPARE has already
succeeded.  init() is called on the CPU_ONLINE and CPU_DOWN_FAILED path.

The issue is there is a two part teardown that can fail and the teardown
fail will be followed by a call to init().

If the timer is not running (stopped in stop()) then there is no reason to
have the memory around. If CPU_DOWN_PREPARE happens followed by CPU_DOWN_FAILED
then intel_pstate is ready for init() to be called with no special case
code.  This maintains the semantics the core expects.


>
> Probably the situation would be exactly same if we divide the exit path into
> stop and exit routines, which I still feel is the right way forward. Because
> ideally cpufreq shouldn't call init() if it hasn't called exit() (If
> it is doing that
> right now then its wrong and can be fixed). And so you must do the cleanup
> in exit()..
>

The core *is* doing this on the CPU_DOWN_FAILED path ATM.

On the CPU_DOWN_FAILED path the core should be undoing the work it did in the
CPU_DOWN_PREPARE path this would require another callback to drivers to let
them "restart" after a call to stop() as well.

I don't think it is worth that level of effort IMHO.

--Dirk

  reply	other threads:[~2014-03-19 15:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKQMxzQhVz0QT6tV0PKFjXXpYpDbtnOBH=miARoeQhrvs2TKFQ@mail.gmail.com>
     [not found] ` <5320D05F.7050304@gmail.com>
     [not found]   ` <5320D12B.4040303@gmail.com>
2014-03-13  0:07     ` intel_pstate: Lower p-state when putting down CPU Rafael J. Wysocki
2014-03-13  4:56       ` Viresh Kumar
2014-03-13 21:39         ` Rafael J. Wysocki
2014-03-14 21:03       ` [PATCH v2 0/2] Add exit_prepare callback to the cpufreq_driver interface dirk.brandewie
2014-03-14 21:03         ` [PATCH v2 1/2] cpufreq: Add exit_prepare callback to " dirk.brandewie
2014-03-15  2:04           ` Rafael J. Wysocki
2014-03-18  5:43             ` Viresh Kumar
2014-03-14 21:03         ` [PATCH v2 2/2] intel_pstate: Set core to min P state during core offline dirk.brandewie
2014-03-18  5:44           ` Viresh Kumar
2014-03-18 15:01             ` Dirk Brandewie
2014-03-18 18:52               ` Srivatsa S. Bhat
2014-03-18 19:44                 ` Dirk Brandewie
2014-03-18 20:15                   ` Srivatsa S. Bhat
2014-03-19  5:20                   ` Viresh Kumar
2014-03-19 15:32                     ` Dirk Brandewie [this message]
2014-03-18 17:22         ` [PATCH v3 0/2] Add stop callback to the cpufreq_driver interface dirk.brandewie
2014-03-18 17:22           ` [PATCH 1/2] cpufreq: Add stop callback to " dirk.brandewie
2014-03-19  5:04             ` Viresh Kumar
2014-03-18 17:22           ` [PATCH 2/2] intel_pstate: Set core to min P state during core offline dirk.brandewie
2014-03-18 19:08             ` Srivatsa S. Bhat
2014-03-18 19:08           ` [PATCH v3 0/2] Add stop callback to the cpufreq_driver interface Srivatsa S. Bhat
2014-03-18 19:25             ` Dirk Brandewie
2014-03-18 20:04               ` Srivatsa S. Bhat
2014-03-19  0:53               ` Rafael J. Wysocki
2014-03-19  5:33                 ` Viresh Kumar
2014-03-19 14:01                   ` Rafael J. Wysocki
2014-03-19 13:49                     ` Viresh Kumar
2014-03-19 14:25                       ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5329B873.7070100@intel.com \
    --to=dirk.brandewie@gmail.com \
    --cc=dirk.j.brandewie@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=patrick.marlier@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.