linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <mpe@ellerman.id.au>
To: sukadev@linux.vnet.ibm.com,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	ak@linux.intel.com, Jiri Olsa <jolsa@redhat.com>,
	peterz@infradead.org, eranian@google.com,
	Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org, dev@codyps.com,
	linux-kernel@vger.kernel.org,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [v2, 1/4] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations
Date: Wed,  1 Oct 2014 11:23:39 +1000 (EST)	[thread overview]
Message-ID: <20141001012339.AD06A14021A@ozlabs.org> (raw)
In-Reply-To: <1411586681-21262-2-git-send-email-sukadev@linux.vnet.ibm.com>

On Wed, 2014-24-09 at 19:24:38 UTC, sukadev@linux.vnet.ibm.com wrote:
> From: Cody P Schafer <cody@linux.vnet.ibm.com>
> 
> Ian pointed out the use of __aligned(4096) caused rather large stack
> consumption in single_24x7_request(), so use the kmem_cache
> hv_page_cache (which we've already got set up for other allocations)
> insead of allocating locally.
> 
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 70d4f74..2f2215c 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -294,7 +294,7 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
>  					 u16 lpar, u64 *res,
>  					 bool success_expected)
>  {
> -	unsigned long ret;
> +	unsigned long ret = -ENOMEM;
>  
>  	/*
>  	 * request_buffer and result_buffer are not required to be 4k aligned,
> @@ -304,7 +304,27 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
>  	struct reqb {
>  		struct hv_24x7_request_buffer buf;
>  		struct hv_24x7_request req;
> -	} __packed __aligned(4096) request_buffer = {
> +	} __packed * request_buffer;

No space after the * please.

> +	struct resb {

You never use the struct name so this can be anonymous, eg:

	struct {
		struct hv_24x7_data_result_buffer buf;
		...

> +		struct hv_24x7_data_result_buffer buf;
> +		struct hv_24x7_result res;
> +		struct hv_24x7_result_element elem;
> +		__be64 result;
> +	} __packed * result_buffer;

No space again.

> +	BUILD_BUG_ON(sizeof(*request_buffer) > 4096);
> +	BUILD_BUG_ON(sizeof(*result_buffer) > 4096);
> +
> +	request_buffer = kmem_cache_alloc(hv_page_cache, GFP_USER);

Why aren't we using kzalloc here?

It looks like we're initialising everything below except the reserved fields,
but are they allowed to be non-zero? It's probably safer to just kzalloc it.

> +	if (!request_buffer)
> +		goto out_reqb;

If prefer labels to be named for what they do, so this would be just "out".

> +
> +	result_buffer = kmem_cache_zalloc(hv_page_cache, GFP_USER);
> +	if (!result_buffer)
> +		goto out_resb;

And this would be "out_free_request_buffer".

> +
> +	*request_buffer = (struct reqb) {
>  		.buf = {
>  			.interface_version = HV_24X7_IF_VERSION_CURRENT,
>  			.num_requests = 1,
> @@ -320,28 +340,30 @@ static unsigned long single_24x7_request(u8 domain, u32 offset, u16 ix,
>  		}
>  	};
>  
> -	struct resb {
> -		struct hv_24x7_data_result_buffer buf;
> -		struct hv_24x7_result res;
> -		struct hv_24x7_result_element elem;
> -		__be64 result;
> -	} __packed __aligned(4096) result_buffer = {};
> -
>  	ret = plpar_hcall_norets(H_GET_24X7_DATA,
> -			virt_to_phys(&request_buffer), sizeof(request_buffer),
> -			virt_to_phys(&result_buffer),  sizeof(result_buffer));
> +			virt_to_phys(request_buffer), sizeof(*request_buffer),
> +			virt_to_phys(result_buffer),  sizeof(*result_buffer));
>  
>  	if (ret) {
>  		if (success_expected)
>  			pr_err_ratelimited("hcall failed: %d %#x %#x %d => 0x%lx (%ld) detail=0x%x failing ix=%x\n",
>  					domain, offset, ix, lpar,
>  					ret, ret,
> -					result_buffer.buf.detailed_rc,
> -					result_buffer.buf.failing_request_ix);
> -		return ret;
> +					result_buffer->buf.detailed_rc,
> +					result_buffer->buf.failing_request_ix);
> +		goto out_hcall;
>  	}
>  
> -	*res = be64_to_cpu(result_buffer.result);
> +	*res = be64_to_cpu(result_buffer->result);
> +	kfree(result_buffer);
> +	kfree(request_buffer);
> +	return ret;
> +
> +out_hcall:
> +	kfree(result_buffer);
> +out_resb:
> +	kfree(request_buffer);
> +out_reqb:
>  	return ret;
>  }

Wouldn't this be better as:

	*res = be64_to_cpu(result_buffer->result);

out_free_result_buffer:
	kfree(result_buffer);
out_free_request_buffer:
	kfree(request_buffer);
out:
	return ret;
}


cheers

  reply	other threads:[~2014-10-01  1:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 19:24 [PATCH v2 0/4] powerpc/perf: Miscellaneous fixes Sukadev Bhattiprolu
2014-09-24 19:24 ` [PATCH v2 1/4] powerpc/perf/hv-24x7: use kmem_cache instead of aligned stack allocations Sukadev Bhattiprolu
2014-10-01  1:23   ` Michael Ellerman [this message]
2014-09-24 19:24 ` [PATCH v2 2/4] Simplify catalog_read() Sukadev Bhattiprolu
2014-10-01  0:32   ` [v2,2/4] " Michael Ellerman
2014-10-01  0:59     ` Sukadev Bhattiprolu
2014-09-24 19:24 ` [PATCH v2 3/4] perf Documentation: sysfs events/ interfaces Sukadev Bhattiprolu
2014-09-24 19:24 ` [PATCH v2 4/4] perf Documentation: remove duplicated docs for powerpc cpu specific events Sukadev Bhattiprolu

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=20141001012339.AD06A14021A@ozlabs.org \
    --to=mpe@ellerman.id.au \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=dev@codyps.com \
    --cc=eranian@google.com \
    --cc=jolsa@redhat.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=sukadev@linux.vnet.ibm.com \
    /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).