Re: [Xen-devel] [PATCH v2 2/2] xen/evtchn: optimize XSM ssid field

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 21.03.14 at 18:43, <dgdegra@xxxxxxxxxxxxx> wrote:
> I'm guessing that swapping the fields and then slipping the flask_sid
> field into the padding as another member of the union would also be
> frowned upon (it seems far more fragile than the __packed method).

How could this be a member of the union in the first place? Isn't
this field applicable to all kinds of event channels?

> The pending bit could be combined with xen_consumer, which currently uses
> only 3 bits (as an index tothe xen_consumers[8] array). This  would make
> the non-XSM struct evtchn take up 28 bytes when arranged properly, and
> the FLASK-only version would then fit in 32.  It seems that xen_consumer
> is used rarely enough that the overhead from it being a bitfield would
> not become an issue; any opinions on this?

That sounds reasonable to me, despite your calculation being not
really correct (even the non-XSM variant of the structure always
occupies 32 bytes, due to the necessary padding at the end in
order to meet the structure's 8-byte alignment requirement).

In fact there are further optimizations possible: For one,
xen_consumer is used actively only for interdomain channels (and
obviously passively for unbound ones), so could be moved into the
union with a little care. And then we could "pickle" remote_dom rather
than storing it as a pointer, shrinking the union from 16 to 8 bytes and
the overall structure to 20/24/32 bytes (non-XSM, FLASK-only, generic-
XSM). But that wouldn't be worthwhile due to EVTCHNS_PER_BUCKET()'s
use of next_power_of_2(), unless we needed to fit in further fields.

While looking at this I started to wonder if the 100k event channel
promise in 4.4 isn't broken: All the *_port fields here are 16-bit only,
and hence only good for around 64k ports. If they all got widened to
32 bits, the structure (with the improvements above) would become
24/28/32 bytes. Widening them without any other adjustments
(thinking of a backport thereof to the 4.4 branch) would appear to
retain the current size.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel