linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Shreyas B Prabhu <shreyas@linux.vnet.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, benh@kernel.crashing.org,
	mahesh@linux.vnet.ibm.com, maddy@linux.vnet.ibm.com
Subject: Re: [PATCH 2/3] powerpc/powernv: Encapsulate idle preparation steps in a macro
Date: Mon, 21 Mar 2016 18:57:30 +0530	[thread overview]
Message-ID: <56EFF6C2.2050503@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160319002122.GA27126@fergus.ozlabs.ibm.com>



On 03/19/2016 05:51 AM, Paul Mackerras wrote:
> On Fri, Mar 18, 2016 at 08:23:24PM +0530, Shreyas B Prabhu wrote:
>> Hi Paul,
>>
>> On 03/17/2016 04:45 PM, Paul Mackerras wrote:
>>> On Mon, Feb 29, 2016 at 05:52:59PM +0530, Shreyas B. Prabhu wrote:
>>>> Before entering any idle state which can result in a state loss
>>>> we currently save the context in the stack before entering idle.
>>>> Encapsulate these steps in a macro IDLE_STATE_PREP. Move this
>>>> and other macros to commonly accessible location.
>>>
>>> There are two problems with this.  First, your new macro does much
>>> more than create a stack frame and save some registers.  It also
>>> messes with interrupts and potentially executes a blr instruction.
>>> That is not what people would expect from the name of the macro or the
>>> comments around it.  It also means that it would be hard to reuse the
>>> macro in another place.
>>>
>>> Secondly, I don't think this change helps readability.  Since the
>>> macro is only used in one place, it doesn't reduce the total number of
>>> lines of code, in fact it increases it slightly. 
>>
>> This patch was in preparation for support for new POWER ISA v3 idle
>> states. The idea was to have the common idle preparation steps in a
>> macro which be reused while adding support for the new idle states. With
>> this context do you think this macro with better comments make sense?
> 
> No, it still does too many disparate things.  In particular it's a bad
> idea to embed a blr inside a macro unless the name makes it very clear
> that the macro can cause a return (e.g. the macro name is
> RETURN_IF_<something>).  Yours would need to be called
> MAKE_STACK_FRAME_AND_SAVE_SPRS_AND_HARD_DISABLE_AND_RETURN_IF_IRQ_OCCURRED
> or something. :)
> 

Ok :) . I'll drop this patch and work this differently.

Thanks,
Shreyas

  reply	other threads:[~2016-03-21 13:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 12:22 [PATCH 0/3] powerpc/powernv: Cpuidle related cleanup Shreyas B. Prabhu
2016-02-29 12:22 ` [PATCH 1/3] powerpc/powernv: Move CHECK_HMI_INTERRUPT to exception-64s header Shreyas B. Prabhu
2016-03-17  5:21   ` Paul Mackerras
2016-02-29 12:22 ` [PATCH 2/3] powerpc/powernv: Encapsulate idle preparation steps in a macro Shreyas B. Prabhu
2016-03-17 11:15   ` Paul Mackerras
2016-03-18 14:53     ` Shreyas B Prabhu
2016-03-19  0:21       ` Paul Mackerras
2016-03-21 13:27         ` Shreyas B Prabhu [this message]
2016-02-29 12:23 ` [PATCH 3/3] powerpc/powernv: Refactor hypervisor state restore code Shreyas B. Prabhu
2016-03-10 10:45 ` [PATCH 0/3] powerpc/powernv: Cpuidle related cleanup Shreyas B Prabhu
2016-03-11  1:00   ` Michael Ellerman

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=56EFF6C2.2050503@linux.vnet.ibm.com \
    --to=shreyas@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --cc=mahesh@linux.vnet.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).