From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Liu Subject: Re: [RFC PATCH 2/2] xen: tmem: make tmem aware of NUMA affinity Date: Thu, 20 Mar 2014 19:59:30 +0800 Message-ID: <532AD822.4060107@oracle.com> References: <1395145511-13381-1-git-send-email-bob.liu@oracle.com> <1395145511-13381-2-git-send-email-bob.liu@oracle.com> <5328665E02000078001252AC@nat28.tlf.novell.com> <20140319171232.GA5247@phenom.dumpdata.com> <532AC23F0200007800126089@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <532AC23F0200007800126089@nat28.tlf.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 Cc: Bob Liu , ian.campbell@citrix.com, andrew.cooper3@citrix.com, dario.faggioli@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 03/20/2014 05:26 PM, Jan Beulich wrote: >>>> On 19.03.14 at 18:12, Konrad Rzeszutek Wilk wrote: >> Would you perhaps reconsider reviewing the code that Bob >> posted and ignore the committing part of it until a later time >> (when tmem has gotten throught the security audit). > > The code looked reasonable, albeit I'm not certain it's to the > point: Aren't certain types of pages sharable between domains? Yes. > For those, setting the affinity based on the domain for which > the allocation gets done doesn't seem ideal. Plus the domain The ideal situation for tmem is try to allocate pages from nodes in domain's node_affinity, if there isn't enough memory on those nodes then fall back to other online nodes. Do you have any suggestion how to implement this? > heap use of tmem was found to be broken anyway, and hence Yes, but I think it's still better if tmem prefers nodes in domain->node_affinity rather than all online nodes. > extending the respective allocation interface seems odd from a > second viewing angle too. > > On the upside of things I would expect to find further uses for > the extended domain page allocation interface. I'm wondering > though whether we couldn't get away without adding yet > another wrapper function: Considering that the passed in > node mask is ignored if d != NULL, making the first argument > a transparent union and adding _MEMF_nodemask to indicate > that the passed in pointer is to a nodemask_t rather than a > struct domain, we could stay with the current single interface. > Inline type-safe accessors to both variants would then seem > to be the way to go. > Thank you for your review! -- Regards, -Bob