All of lore.kernel.org
 help / color / mirror / Atom feed
From: Corneliu ZUZU <czuzu@bitdefender.com>
To: xen-devel@lists.xen.org
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <jbeulich@suse.com>
Subject: X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE
Date: Fri, 29 Jan 2016 18:24:18 +0200	[thread overview]
Message-ID: <56AB9232.3050300@bitdefender.com> (raw)

I'm trying to refactor some arch-specific code into common code and was 
surprised to find out that the x86 domain structure already occupies 
PAGE_SIZE bytes, couldn't even add an unsigned short field in it w/o 
causing a compile-time error.
I'm using the master branch of git://xenbits.xenproject.org/xen.git, 
compiled Xen by simply running "./configure && make dist-xen" (on my 
x86_64 Ubuntu machine).

Concretely, the change that caused problems was the refactoring of the 
x86 arch_domain.monitor field [@ xen/include/asm-x86/domain.h], which 
originally was:
      struct {
         unsigned int write_ctrlreg_enabled       : 4;
         unsigned int write_ctrlreg_sync          : 4;
         unsigned int write_ctrlreg_onchangeonly  : 4;
         unsigned int mov_to_msr_enabled          : 1;
         unsigned int mov_to_msr_extended         : 1;
         unsigned int singlestep_enabled          : 1;
         unsigned int software_breakpoint_enabled : 1;
         unsigned int guest_request_enabled       : 1;
         unsigned int guest_request_sync          : 1;
      } monitor;

by leaving there only the x86-specific part, i.e.:
      struct {
         uint8_t mov_to_msr_enabled          : 1;
         uint8_t mov_to_msr_extended         : 1;
      } monitor;

and moving the rest directly into the domain structure, i.e. add @ the 
end of struct domain [@ xen/include/xen/sched.h]:
      struct {
         uint16_t write_ctrlreg_enabled       : 4;
         uint16_t write_ctrlreg_sync          : 4;
         uint16_t write_ctrlreg_onchangeonly  : 4;
         uint16_t singlestep_enabled          : 1;
         uint16_t software_breakpoint_enabled : 1;
         uint16_t guest_request_enabled       : 1;
         uint16_t guest_request_sync          : 1;
      } monitor;

After the above change, X86 compilation of [xen/arch/x86/domain.c] fails w/:
     error: static assertion failed: "!(sizeof(*d) > PAGE_SIZE)"
the line that caused the fail being:
     BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);

To investigate I compiled the unaltered domain.c & used the pahole tool 
(part of dwarves package) to obtain the complete layout of the domain 
structure (& its members).
What I obtained:
     * sizeof(struct domain) is already = 4096 bytes (= PAGE_SIZE)
     * sizeof(struct arch_domain) [x86] = sizeof(domain.arch) = 3328 
bytes (arch_domain is marked __cacheline_aligned, i.e. aligned to 128 bytes)
     * sizeof(domain.arch.hvm_domain) = 2224 bytes
     * sizeof(domain.arch.hvm_domain.pl_time) = 1088 bytes

=> overall, X86 timers-related information occupies the most.

One could shrink the domain structure by transforming some of its fields 
to pointers, e.g. I could transform the pl_time field into a pointer and 
dynamically allocate its data when domain_create is called.
Since the domain structure was designed to fit in a single page & 
arch_domain is marked __cacheline_aligned I presume such changes are 
sensible and should be done wisely.

How I should proceed?

Thank you,
Corneliu.

             reply	other threads:[~2016-01-29 16:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-29 16:24 Corneliu ZUZU [this message]
2016-01-29 16:47 ` X86 arch_domain ginormous, sizeof(struct domain) already == PAGE_SIZE Lengyel, Tamas
2016-01-29 21:32   ` Corneliu ZUZU
2016-01-31  0:22     ` Lengyel, Tamas
2016-01-29 17:09 ` Jan Beulich
2016-01-29 17:12   ` Andrew Cooper
2016-01-29 21:45   ` Corneliu ZUZU

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=56AB9232.3050300@bitdefender.com \
    --to=czuzu@bitdefender.com \
    --cc=andrew.cooper3@citrix.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.