xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH v2 2/2] xen/evtchn: optimize XSM ssid field
Date: Fri, 21 Mar 2014 15:16:35 +0000	[thread overview]
Message-ID: <532C57D3.60509@citrix.com> (raw)
In-Reply-To: <532C52B2.10206@tycho.nsa.gov>

On 21/03/14 14:54, Daniel De Graaf wrote:
> On 03/21/2014 09:28 AM, David Vrabel wrote:
>> On 20/03/14 15:29, Daniel De Graaf wrote:
>>> When FLASK is the only enabled implementation of the XSM hooks in Xen,
>>> some of the abstractions required to handle multiple XSM providers are
>>> redundant and only produce unneeded overhead.  This patch reduces the
>>> memory overhead of enabling XSM on event channels by replacing the
>>> untyped ssid pointer from struct evtchn with a union containing the
>>> contents of the structure.  This avoids an additional heap allocation
>>> for every event channel, and on 64-bit systems, reduces the size of
>>> struct evtchn by 4 bytes.
>>
>> Without XSM the 64-bit structure is 29 bytes (so 32 including the
>> trailing padding).
>>
>> Adding a 4 byte word or a 8 byte word both results in a 40 byte
>> structure which halves the number of evtchns per page (since each page
>> contains a power of two structs).
>>
>> I think you could swap the order of the fields in u.interdomain to get
>> better packing with the 4 byte flask_sid and end up with a 32 byte
>> struct evtchn (there's 6 bytes of padding between remote_port and
>> remote_dom).
>>
>> You may want to check the EVTCHNS_PER_BUCKET value before/after.
>>
>> David
> 
> Making this work correctly requires adding__packed to the interdomain
> structure (otherwise, the padding just remains at the end); with this,
> the structure is 24 bytes without XSM, 28 with FLASK only, and 32 with
> XSM_NEED_GENERIC_EVTCHN_SSID (all with one byte of padding remaining).

Oh, now I remember why I didn't do this before.  Sorry for wasting your
time.

David

  parent reply	other threads:[~2014-03-21 15:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20 15:29 [PATCH v2 1/2] xen/xsm: Reduce compiler command line clutter Daniel De Graaf
2014-03-20 15:29 ` [PATCH v2 2/2] xen/evtchn: optimize XSM ssid field Daniel De Graaf
2014-03-20 15:59   ` Jan Beulich
2014-03-21 13:28   ` David Vrabel
2014-03-21 14:54     ` Daniel De Graaf
2014-03-21 15:00       ` Jan Beulich
2014-03-21 15:16       ` David Vrabel [this message]
2014-03-21 17:43         ` Daniel De Graaf
2014-03-24  8:38           ` Jan Beulich
2014-03-24 10:53             ` David Vrabel
2014-03-24  9:07   ` Keir Fraser
2014-03-20 15:54 ` [PATCH v2 1/2] xen/xsm: Reduce compiler command line clutter Jan Beulich
2014-03-24  9:05 ` Keir Fraser

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=532C57D3.60509@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.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).