Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp199624pxk; Thu, 24 Sep 2020 03:31:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwltz4hsKGwqiXgVYK4hsPuDPeRGTAXIkHypzm0THBwxG40tmBSaFTgyRW3tMmhNHqKr242 X-Received: by 2002:a17:906:49cb:: with SMTP id w11mr253962ejv.530.1600943466993; Thu, 24 Sep 2020 03:31:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600943466; cv=none; d=google.com; s=arc-20160816; b=is9oPmP5P/Z4f2AUhWEtUANzknIJVKoSYl0nLhWDrAT9sxdgXi03NAX9oheYMv9DqH 2t54lhsCyT7sUDmNpeuoXe9rh0THF6OM5hFbGEqCtfdu4FP1xD5ZigTS9DyelQPPTOi8 tRuTbzHw1Kc9ptcNYVN1uNdFtwqwFuslmqt9XfogCiMtonrjOy9UUNt5TOsvWiRbVG/H 4fSZTzEJg5TYIDSJa30lGlT7LA3ldrK5NJST/wMlEj7VFvTbMxyDsHRsFpPoM3227IkX tfg+RMgLF1CXit+YyOpVl4yEJ0BIPhnTb+CVnM1O5OgIBMZ8X772Xu6ujP+Fw+4PeM4T 21dw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:message-id:date:subject:cc:to:from:dkim-signature; bh=VJUxKkMgAakbT3L/fC0FIlc1ypeBbbtBZnjUiDl52NU=; b=nLmNraOyM1jpi0JvITot6CuEgUwQXA2XI1Qn+RZAHGTw2OQWiTeO47fOYUBRRDenOS 2TzaSGnaEM0znI5GfPgIYAbUn467G/OVVhTqyQe2OBQWd2/9/a6iJqbXex4CBVGLpZXh GZGpPLbV6nr5A6lv7SWwdbTfypkFkMF2BzKKfAs5Z6mYD9lS8DnHQ/jBfGt/90yxS88y 0GGeq0p6eaL3q0K0WngJmp/NhD4hsvuVbqgN1hC56Gi3Js25uixSXDYsrLpn96TiWYbY JsDW/E5sZXEKf2ueC2+YyzW1wiDJLOmVO8CjpGjNCBJJosjB7gchcwB3+sJQ16NMVUtY WT3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amazon.com header.s=amazon201209 header.b=fb5sAyVC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l19si1811323edq.264.2020.09.24.03.30.43; Thu, 24 Sep 2020 03:31:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@amazon.com header.s=amazon201209 header.b=fb5sAyVC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amazon.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727386AbgIXK1j (ORCPT + 99 others); Thu, 24 Sep 2020 06:27:39 -0400 Received: from smtp-fw-9102.amazon.com ([207.171.184.29]:29046 "EHLO smtp-fw-9102.amazon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727349AbgIXK1j (ORCPT ); Thu, 24 Sep 2020 06:27:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1600943259; x=1632479259; h=from:to:cc:subject:date:message-id:mime-version: in-reply-to:content-transfer-encoding; bh=VJUxKkMgAakbT3L/fC0FIlc1ypeBbbtBZnjUiDl52NU=; b=fb5sAyVCrxy+m4pUK3gJZNPiyH7ZBuNt7jXfNRy2TnH4dYY8VsFS/jWh xgo4Z4a9Q7U5+gQx1N+U0cPQXI2s0DMjrOmSBgN/8Nc9DxhMmEErwDHM6 h3J7z2L4677ZRxYipY4ur3IMu3p+S568yhS5ko0fs0HOxUAYGisxB8ACX o=; X-IronPort-AV: E=Sophos;i="5.77,297,1596499200"; d="scan'208";a="78889262" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-55156cd4.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 24 Sep 2020 10:27:37 +0000 Received: from EX13D31EUA004.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-55156cd4.us-west-2.amazon.com (Postfix) with ESMTPS id A14B3A1FF9; Thu, 24 Sep 2020 10:27:36 +0000 (UTC) Received: from u3f2cd687b01c55.ant.amazon.com (10.43.160.244) by EX13D31EUA004.ant.amazon.com (10.43.165.161) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 24 Sep 2020 10:27:30 +0000 From: SeongJae Park To: =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= CC: Konrad Rzeszutek Wilk , SeongJae Park , SeongJae Park , , , , , , , Subject: Re: [PATCH] xen-blkback: add a parameter for disabling of persistent grants Date: Thu, 24 Sep 2020 12:27:14 +0200 Message-ID: <20200924102714.28141-1-sjpark@amazon.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 In-Reply-To: <20200924101344.GN19254@Air-de-Roger> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.43.160.244] X-ClientProxiedBy: EX13D40UWC004.ant.amazon.com (10.43.162.175) To EX13D31EUA004.ant.amazon.com (10.43.165.161) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 Sep 2020 12:13:44 +0200 "Roger Pau Monné" wrote: > On Wed, Sep 23, 2020 at 04:09:30PM -0400, Konrad Rzeszutek Wilk wrote: > > On Tue, Sep 22, 2020 at 09:01:25AM +0200, SeongJae Park wrote: > > > From: SeongJae Park > > > > > > Persistent grants feature provides high scalability. On some small > > > systems, however, it could incur data copy overhead[1] and thus it is > > > required to be disabled. But, there is no option to disable it. For > > > the reason, this commit adds a module parameter for disabling of the > > > feature. > > > > Would it be better suited to have it per guest? > > I think having a per-backend policy that could be specified at the > toolstack level would be nice, but I see that as a further > improvement. Agreed. > > Having a global backend domain policy of whether persistent grants are > enabled or not seems desirable, and if someone wants even more fine > grained control this change is AFAICT not incompatible with a > per-backend option anyway. I think we could extend this design by receiving list of exceptional domains. For example, if 'feature_persistent' is True and exceptions list has '123, 456', domains of domid 123 and 456 will not use persistent grants, and vice versa. I could implement this, but... to be honest, I don't really understand the needs of the fine-grained control. AFAIU, the problem is 'scalability' vs 'data copy overhead'. So, only small systems would want to turn persistent grants off. In such a small system, why would we need fine-grained control? I'm worrying if I would implement and maintain a feature without real use case. For the reason, I'd like to suggest to keep this as is for now and expand it with the 'exceptions list' idea or something better, if a real use case comes out later. Thanks, SeongJae Park