From: Eric Farman <farman@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>, Farhan Ali <alifm@linux.ibm.com>
Cc: Halil Pasic <pasic@linux.ibm.com>,
linux-s390@vger.kernel.org, kvm@vger.kernel.org,
Eric Farman <farman@linux.ibm.com>
Subject: [RFC PATCH v1 0/5] s390: more vfio-ccw code rework
Date: Tue, 18 Jun 2019 22:23:47 +0200 [thread overview]
Message-ID: <20190618202352.39702-1-farman@linux.ibm.com> (raw)
A couple little improvements to the malloc load in vfio-ccw.
Really, there were just (the first) two patches, but then I
got excited and added a few stylistic ones to the end.
The routine ccwchain_calc_length() has this basic structure:
ccwchain_calc_length
a0 = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1))
copy_ccw_from_iova(a0, src)
copy_from_iova
pfn_array_alloc
b = kcalloc(len, sizeof(*pa_iova_pfn + *pa_pfn)
pfn_array_pin
vfio_pin_pages
memcpy(a0, src)
pfn_array_unpin_free
vfio_unpin_pages
kfree(b)
kfree(a0)
We do this EVERY time we process a new channel program chain,
meaning at least once per SSCH and more if TICs are involved,
to figure out how many CCWs are chained together. Once that
is determined, a new piece of memory is allocated (call it a1)
and then passed to copy_ccw_from_iova() again, but for the
value calculated by ccwchain_calc_length().
This seems inefficient.
Patch 1 moves the malloc of a0 from the CCW processor to the
initialization of the device. Since only one SSCH can be
handled concurrently, we can use this space safely to
determine how long the chain being processed actually is.
Patch 2 then removes the second copy_ccw_from_iova() call
entirely, and replaces it with a memcpy from a0 to a1. This
is done before we process a TIC and thus a second chain, so
there is no overlap in the storage in channel_program.
Patches 3-5 clean up some things that aren't as clear as I'd
like, but didn't want to pollute the first two changes.
For example, patch 3 moves the population of guest_cp to the
same routine that copies from it, rather than in a called
function. Meanwhile, patch 4 (and thus, 5) was something I
had lying around for quite some time, because it looked to
be structured weird. Maybe that's one bridge too far.
Eric Farman (5):
vfio-ccw: Move guest_cp storage into common struct
vfio-ccw: Skip second copy of guest cp to host
vfio-ccw: Copy CCW data outside length calculation
vfio-ccw: Factor out the ccw0-to-ccw1 transition
vfio-ccw: Remove copy_ccw_from_iova()
drivers/s390/cio/vfio_ccw_cp.c | 108 +++++++++++---------------------
drivers/s390/cio/vfio_ccw_cp.h | 7 +++
drivers/s390/cio/vfio_ccw_drv.c | 7 +++
3 files changed, 52 insertions(+), 70 deletions(-)
--
2.17.1
next reply other threads:[~2019-06-18 20:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 20:23 Eric Farman [this message]
2019-06-18 20:23 ` [RFC PATCH v1 1/5] vfio-ccw: Move guest_cp storage into common struct Eric Farman
2019-06-19 8:14 ` Cornelia Huck
2019-06-19 20:13 ` Farhan Ali
2019-06-19 20:53 ` Eric Farman
2019-06-19 21:12 ` Farhan Ali
2019-06-18 20:23 ` [RFC PATCH v1 2/5] vfio-ccw: Skip second copy of guest cp to host Eric Farman
2019-06-19 8:17 ` Cornelia Huck
2019-06-18 20:23 ` [RFC PATCH v1 3/5] vfio-ccw: Copy CCW data outside length calculation Eric Farman
2019-06-19 8:18 ` Cornelia Huck
2019-06-18 20:23 ` [RFC PATCH v1 4/5] vfio-ccw: Factor out the ccw0-to-ccw1 transition Eric Farman
2019-06-19 8:22 ` Cornelia Huck
2019-06-18 20:23 ` [RFC PATCH v1 5/5] vfio-ccw: Remove copy_ccw_from_iova() Eric Farman
2019-06-19 8:23 ` Cornelia Huck
2019-06-19 21:13 ` Farhan Ali
2019-06-19 8:25 ` [RFC PATCH v1 0/5] s390: more vfio-ccw code rework Cornelia Huck
2019-06-19 11:11 ` Eric Farman
2019-06-19 21:15 ` Farhan Ali
2019-06-21 12:25 ` Cornelia Huck
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=20190618202352.39702-1-farman@linux.ibm.com \
--to=farman@linux.ibm.com \
--cc=alifm@linux.ibm.com \
--cc=cohuck@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pasic@linux.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).