[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xen-unstable test] 164996: regressions - FAIL

  • To: Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 22 Sep 2021 15:26:49 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FNsIFDNt/dpD1F3IS8KbBBhMWnQiexgrzg+BE6l5F6Q=; b=f7kY+Sg4Dg+w70ecf8x2dRNdslUdFG8YEn8LnxI6He8UTj26jv9ECUX3Bp+6mSuXyHFcEYVtJVdtfwArMn9geFojU52aUBChWzh25Dj4IoDXVpsrxRjRrWdLnHrfNaadzI2rgU1sCcXkf+NxoV16vxRVxDElWkt1DLO9EFewe0yVz8r5SfCZFRWvY6Bmr4hMxDaOpIsZlE6fg/YlbvORnNM/EtGcIEC2aoAM4oGsmmiX7gc5xAZvPKtHgnkM9d3sK7U7u2HralUWOqP98D3KWvNxsdw/0s1mlKmn7IkANB10rkneuskw0Bfo1Mhe+DwS9NqhrSzUkn8xiznuFPLWDw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PRs5LoeUcFgae5JqpPH7QLmRX8Dh3KkDiAJ/yc1VogPzfFovEpSLT6XBup1X8fwfp5x4BYLwE1BVznCcoEWt0X/jmaD5LQH5pu5Y993GcGF6kGgCkzGuPOgbJoUitCyuUzxvmDYHefR+Vdxs65b+W4C2Shqry9mu8DWnhiLNV42zbHuYvJxJXtx0ZmpiFh+8Y1Qh0okwACR7F0ixtsZ4Lu9EPK8HwPpMxgJLoRKWUeYt2Kwmb2I+QugCdj1AthYBcnroE/1OZOrUoLm259vsQUoJecL6TU08/OvMZmDXUGCVDxgJO7mwce4JEAmwXbQ6uFUPuwTh12Idh09vTQLI/w==
  • Authentication-results: apertussolutions.com; dkim=none (message not signed) header.d=none;apertussolutions.com; dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, dpsmith@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 22 Sep 2021 13:27:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.09.2021 14:29, Ian Jackson wrote:
> I'm not sure, though, that I fully understand the design principles
> behind non-order-0 allocations, and memory sizing, and so on.  Your
> earlier mail suggeted there may not be a design principle, and that
> anything relying on non-order-0 atomic allocations is only working by
> luck (or an embarassing excess of ram).

That's what I think, yes. During boot and in certain other specific
places it may be okay to use such allocations, as long as failure
leads to something non-destructive. A process (or VM) not getting
created successfully _might_ be okay; a process or VM failing when
it already runs is not okay. Just to give an example. The situation
here falls in the latter category, at least from osstest's pov. IOW
assuming that what gets tested is a goal in terms of functionality,
VM creation failing when there is enough memory (just not in the
right "shape") is not okay here. Or else the test was wrongly put
in place.

Therefore a goal I've been trying to follow in the hypervisor is to
eliminate higher order allocations wherever possible. And I think
the kernel wants to follow suit here.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.