From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCHv4 8/8] x86: reduce struct hvm_domain size Date: Mon, 11 May 2015 14:17:40 +0100 Message-ID: <5550ABF4.5040904@citrix.com> References: <1430408002-30666-1-git-send-email-david.vrabel@citrix.com> <1430408002-30666-9-git-send-email-david.vrabel@citrix.com> <554CA26E02000078000781E6@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yrnac-0005yu-JV for xen-devel@lists.xenproject.org; Mon, 11 May 2015 13:17:46 +0000 In-Reply-To: <554CA26E02000078000781E6@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , David Vrabel Cc: Keir Fraser , Ian Campbell , Andrew Cooper , Jennifer Herbert , Tim Deegan , xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org On 08/05/15 10:47, Jan Beulich wrote: >>>> On 30.04.15 at 17:33, wrote: >> Pack struct hvm_domain to reduce it by 8 bytes. Thus reducing the >> size of struct domain by 8 bytes. > > Is that really true _after_ the change to ticket locks? Yes. >> @@ -137,6 +131,12 @@ struct hvm_domain { >> bool_t is_s3_suspended; >> bool_t introspection_enabled; >> >> + /* If one of vcpus of this domain is in no_fill_mode or >> + * mtrr/pat between vcpus is not the same, set is_in_uc_mode >> + */ >> + bool_t is_in_uc_mode; >> + spinlock_t uc_lock; >> + >> /* >> * TSC value that VCPUs use to calculate their tsc_offset value. >> * Used during initialization and save/restore. > > And here it follows 5 bool_t-s, and is being followed by an 8-byte > aligned field. I.e. without ticket locks it exactly fills the 3 byte gap, > but with ticket locks it requires a second 8-byte slot. No. The old byte locks were 4-bytes in size (not 2 bytes). > Additionally I wonder whether the reduced distance between > uc_lock and msixtbl_list_lock would now lead to (or, going forward, > at least risk) them being on the same cache line. They're still on different cache lines. David