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