Received: by 2002:a05:7412:8d09:b0:fa:4c10:6cad with SMTP id bj9csp217245rdb; Mon, 15 Jan 2024 19:27:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IH5Hyvvh5o4URt1KyfWTgFq+jCr63FM2HIApP9Ysu6IyDbV4xqE8U5pUCDMJhrD9onwf4n6 X-Received: by 2002:a05:6808:2e9b:b0:3bd:7296:76af with SMTP id gt27-20020a0568082e9b00b003bd729676afmr5863538oib.19.1705375631794; Mon, 15 Jan 2024 19:27:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705375631; cv=none; d=google.com; s=arc-20160816; b=U7mAzOgEC07Fxa91a0O90UJPbjcLMj1LfqluBTXejZvB/HDaqfRrL+ymaFKaEiOyH5 ArFHEc7rtlrW3HyrXbhjk7bVm8zMWv4DS+hSeojHzvyjWfFIr1U4EbQ+7CcTa/5Z0aRq toInEtyFL2HeiwuyOejG/xX+HBJi7x19X5kZ60BMtxrspdd9sVecIfCm4oi5cILivYpA vnJQSjiCCi26X3XecKP2qRXRwrhUKLyI95nHCXWSCcEOZG4JQHrPFYEqJTN+WayDeUpu 6AtoMgmsiHB5R0icNpZVHV4YmUehU8D58BttLIziUhtWkWfgY5qKYof2j0IHboPQmfAY LTXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:subject:cc:to:from:content-language :user-agent:mime-version:list-unsubscribe:list-subscribe:list-id :precedence:date:message-id; bh=i4TKFyo1ymfI2TubB5PW1sOmFQqDhsKl5qqPzM0dyZI=; fh=8rkp9NeDT3lGk9Ucnx6zozmqQuAYyW26cHSgouYLNs0=; b=HJ13siiQ9QLBE3fQR3hJE9JPEmkSGnx3lVTWot8oIpb7fhRDtoDrM64u2HEr4kwGd5 GRUhtyISndYIQrJQZg2c1F7mjoaongO3qTaKg/6v3DtV9rD1psrShhRUmciogXGJxgGT 20U6MVrr1uSfkJRTUzH0xc4kAMYzZmxX6QMA/6BIthCYZLJ18/BMKMcZPN7ylqXNT0nl ZBYdzdMLAAknTfByz4TVwGAiPKUNHl9NiOjSl6DVoQ3wiSEjA47r2mMyUYfYkFsF5oLW o4hv4MLtg3t05XslLqAWoG4bs+or71y3jKfjgx4MOOn8r2FjMUWbXibRPsmNpUlJ/Vkj 8U5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-26939-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26939-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id x6-20020a17090a8a8600b0028d0327922dsi12641193pjn.78.2024.01.15.19.27.11 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 19:27:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-26939-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-26939-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-26939-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id C704BB22734 for ; Tue, 16 Jan 2024 03:27:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2C05A747C; Tue, 16 Jan 2024 03:26:58 +0000 (UTC) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D15DD6FC8 for ; Tue, 16 Jan 2024 03:26:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.105]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4TDZCF1jR4zvTrP; Tue, 16 Jan 2024 11:25:29 +0800 (CST) Received: from dggpeml500004.china.huawei.com (unknown [7.185.36.140]) by mail.maildlp.com (Postfix) with ESMTPS id 8349614053B; Tue, 16 Jan 2024 11:26:37 +0800 (CST) Received: from [10.174.186.25] (10.174.186.25) by dggpeml500004.china.huawei.com (7.185.36.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 16 Jan 2024 11:26:25 +0800 Message-ID: Date: Tue, 16 Jan 2024 11:26:08 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Content-Language: en-US From: "sundongxu (A)" To: , , , , , , CC: , , , Subject: [bug report] GICv4.1: VM performance degradation due to not trapping vCPU WFI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpeml500004.china.huawei.com (7.185.36.140) Hi Guys, We found a problem about GICv4/4.1, for example: We use QEMU to start a VM (4 vCPUs and 8G memory), VM disk was configured with virtio, and the network is configured with vhost-net, the CPU affinity of the vCPU and emulator is as follows, in VM xml: Running Mysql in the VM, and sysbench (Mysql benchmark) on the host, the performance index is tps, the higher the better. If the host only enabled GICv3, the tps will be around 1400. If the host enabled GICv4.1, other configurations remain unchanged, the tps will be around 40. We found that when the host enabled GICv4.1, because vSGI is directly injected to VM, and most time vCPU exclusively occupy the pCPU, vCPU will not trap when executing the WFI instruction. Then from the host view, the CPU usage of vCPU0~vCPU3 is almost 100%. When running mysql service in VM, the vhost-net and qemu processes also need to obtain enough CPU time, but unfortunately these processes cannot get that much time (for example, only GICv3 enabled, the cpu usage of vhost-net is about 43%, but with GICv4.1 enabled, it becomes 0~2%). During the test, it was found that vhost-net sleeps and wakes up very frequently. When vhost-net wakes up, it often cannot obtain CPU in time (because of wake-up preemption check). After waking up, vhost-net will usually run for a short period of time before going to sleep again. If the host enabled GICv4.1, and force vCPU to trap when executing WFI, the tps will be around 1400. On the other hand, when vCPU executes WFI instruction without trapping, the vcpu wake-up delay will be significantly improved. For example, the result of running cyclictest in VM: WFI trap 6us WFI no trap 2us Currently, I add a KVM module parameter to control whether the vCPU traps (by set or clear HCR_TWI) when executing the WFI instruction with host enabled GICv4/4.1, and by default, vCPU traps are set. Or, it there a better way?