From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: eliminating 166G limit (was Re: Problem with nr_nodes on large memory NUMA machine) Date: Tue, 27 Nov 2007 09:51:01 +0000 Message-ID: <474BF695.76E4.0078.0@novell.com> References: <474BEACC.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 27.11.07 10:21 >>> >On 27/11/07 09:00, "Jan Beulich" wrote: > >>> I don't get how your netback approach works. The pages we transfer do = not >>> originate from netback, so it has little control over them. And, even = if it >>> did, when we allocate pages for network receive we do not know which >>> domain's packet will end up in each buffer. >>=20 >> Oh, right, I mixed up old_mfn and new_mfn in netbk_gop_frag(). = Nevertheless >> netback could take care of this by doing the copying there, as at that = point i >> already knows the destination domain. > >You may not know constraints on that domain's max_mfn though. We could = add >an interface to Xen to interrogate that, but generally it's not something = we >probably want to expose outside of Xen and the guest itself. What constraints other than the guest's address size influence its = max_mfn? Of course, if there's anything beyond the address size, then having a way = to obtain the constraint explicitly would be desirable. But otherwise (and as fallback) using 37 bits (128G) seems quite reasonable. >>> Personally I think doing it in Xen is perfectly good enough for = supporting >>> this very out-of-date network receive mechanism. >>=20 >> I'm not just concerned about netback here. The interface exists, and = other >> users might show up and/or exist already. Whether it would be acceptable= >> for them to do allocation and copying is unknown. You'd therefore = either >> need a way to prevent future users of the transfer mechanism, or set = proper >> requirements on its use. I think that placing extra requirements on the = user >> of the interface is better than introducing extra (possibly hard to = reproduce/ >> recognize/debug) possibilities of failure. > >The interface is obsolete. Then it should be clearly indicated as such, e.g. by a mechanism similar = to deprecated_irq_flag() in Linux 2.6.22. And as a result, its use in netback = should then probably be conditional upon an extra config option, which could at = once be used to provide a note to Xen that the feature isn't being used so that = the function could return -ENOSYS and the clipping could be avoided/reverted. Jan