From nobody Tue Apr 23 07:21:46 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 78.46.105.101 is neither permitted nor denied by domain of seabios.org) client-ip=78.46.105.101; envelope-from=seabios-bounces@seabios.org; helo=coreboot.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 78.46.105.101 is neither permitted nor denied by domain of seabios.org) smtp.mailfrom=seabios-bounces@seabios.org; dmarc=fail(p=none dis=none) header.from=virtuozzo.com ARC-Seal: i=1; a=rsa-sha256; t=1571670464; cv=none; d=zoho.com; s=zohoarc; b=SovphYJqdE1wRdYrEuW0fm16VFpT3ys99tKtj2vX6nIslZbT4R/gGYK3jvjcpABHtMyXF27D9LsdFJJFKbFIUpYSsspGqiMeGfPOfZiCl6wmZCWASz6b0beWpfTNpXhJ/XXF013mbgo6aQavQmbQfoozAwctnKf97ULz2DL00V0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1571670464; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Subject:To; bh=P4Zo05cmFa2EZI6eWH6yRXphHF7h3LfQcwMzvjT8ywc=; b=hMbgfEjZTdL0o0DbSB3lrBivv0K9XZZyxlnzAh9jof285fkJ3pR5JCL4Dm2wDxfwStIykgQe0UfKyaqjvodK0JbkEJablPPmNrFvsaWdtQgl2YvD4NMU+tc0pnxZP44D94KZ2wYkMFrx8eHdyX7hPNfBbwY+phBIByAmcxI83Ek= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 78.46.105.101 is neither permitted nor denied by domain of seabios.org) smtp.mailfrom=seabios-bounces@seabios.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from coreboot.org (coreboot.org [78.46.105.101]) by mx.zohomail.com with SMTPS id 1571670464044615.9853023421365; Mon, 21 Oct 2019 08:07:44 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by coreboot.org (Postfix) with ESMTPA id 8305712ABC8C; Mon, 21 Oct 2019 15:07:40 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by coreboot.org (Postfix) with ESMTP id 9FFD212A0F12 for ; Thu, 17 Oct 2019 14:01:07 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by relay.sw.ru with esmtp (Exim 4.92.2) (envelope-from ) id 1iL6Kw-00074i-3t; Thu, 17 Oct 2019 17:01:06 +0300 From: Denis Plotnikov To: kraxel@redhat.com Date: Thu, 17 Oct 2019 17:01:00 +0300 Message-Id: <20191017140100.8325-1-dplotnikov@virtuozzo.com> X-MailFrom: dplotnikov@virtuozzo.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-seabios.seabios.org-0; header-match-seabios.seabios.org-1 Message-ID-Hash: PXGUFUZ2NT7GORNB2OQU72SH7QXJRISC X-Message-ID-Hash: PXGUFUZ2NT7GORNB2OQU72SH7QXJRISC X-Mailman-Approved-At: Mon, 21 Oct 2019 15:07:03 +0000 CC: seabios@seabios.org, den@virtuozzo.com X-Mailman-Version: 3.2.3 Precedence: list Subject: [SeaBIOS] [PATCH v1] virtio: extend virtio queue size to 256 List-Id: SeaBIOS mailing list Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: +++++ X-Spam-Level: ***** Authentication-Results: coreboot.org; auth=pass smtp.auth=mailman@coreboot.org smtp.mailfrom=seabios-bounces@seabios.org Content-Type: text/plain; charset="utf-8" v1: * more verbose commit message [Gerd] --- The goal of the patch is to work around a performance bug in guest linux kernels. Old linux kernels has a performance flaw in virtio block device access: on some frequent disk access patterns, e.g. 1M read, the kernel produces more block requests than needed. This happens because of virtio seg_max parameter set to 126 (virtqueue_size - 2) which limits the maximum block request to 516096 (126 * 4096_PAGE_SIZE) bytes. Setting seg_max > 126 fixes the issue, however, not all linux kernels allow that without increasing virtio virtqueue size. The old kernels have a restriction: virtqueue_size >=3D seg_max. In case of the restriction violation the old kernels crash. The restriction is relaxed in the recent linux kernels (ver >=3D 4.13) with: commit 44ed8089e991a60d614abe0ee4b9057a28b364e4 Author: Richard W.M. Jones Date: Thu Aug 10 17:56:51 2017 +0100 scsi: virtio: Reduce BUG if total_sg > virtqueue size to WARN. and the recent linux kernels don't crash if total_sg > virtqueue size allowing to set seg_max to the needed value without virtqueue size increasing. To fix the performance flaw in the old linux kernels, it's needed to increse seg_max to 254, and comply the restriction by setting virtqueue_size to 256. This is achievable if seabios can support virtqueue size > 128 which this patch actually does. Windows kernels don't have virtqueue_size >=3D seg_max restriction and isn't affected with this kind of the performance bug. Signed-off-by: Denis Plotnikov --- src/hw/virtio-ring.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h index 8604a01..dccc50d 100644 --- a/src/hw/virtio-ring.h +++ b/src/hw/virtio-ring.h @@ -20,7 +20,7 @@ #define VIRTIO_F_VERSION_1 32 #define VIRTIO_F_IOMMU_PLATFORM 33 =20 -#define MAX_QUEUE_NUM (128) +#define MAX_QUEUE_NUM (256) =20 #define VRING_DESC_F_NEXT 1 #define VRING_DESC_F_WRITE 2 --=20 2.17.0 _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org