kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


             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).