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
next prev parent 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).