From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from va-1-115.ptr.blmpb.com (va-1-115.ptr.blmpb.com [209.127.230.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39C183559C5 for ; Tue, 13 Jan 2026 06:38:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.127.230.115 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768286325; cv=none; b=FQUfmOj0q/EHxHf4pqkt1DwQc0BT68JBbq7eEeMG04vE9dQUJKBbk4WYy47PwOgiH0TfjYdUoq/zVQ4g8l+66yIHnz/X5yM4qwoG5LQnC+uyPIVvA+z2WF7PGZ6iw9skXRB3ge+bqny+B9ueD91/zt/D2NwItKvwiPnfBbYMmvM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768286325; c=relaxed/simple; bh=cztTSB3ca96PNNbv9h2Oh63P6qoiaXiF9SRcoEyOaP4=; h=Content-Type:Cc:References:To:Date:Subject:Message-Id: Mime-Version:From:In-Reply-To; b=k3PquIZAy2VHDZh43o39zcq12YzsJhcVQSg3ZP2TAigN5jUUnjObDjE+V960O2D1BalxORxUdAzDG1TDDtj+xhWeI1kcX82Q0ZRxjLa3D4NLta0pH8LqMOb7IXbn34FriNGmf9yknPRLKJ1eZvUKsdSCWGhFV9yyTom7aOR5O0U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=ffW932ut; arc=none smtp.client-ip=209.127.230.115 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="ffW932ut" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1768286273; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=aHB2VTiwHe/vc3UmYyzgVrx5abBH1msD+t9uqXPLaOg=; b=ffW932utukX2ji4yKL/XCqnUtgBCNXXitjmbIo6D9zbh2MJncPFR/O7EW46QssUG7pxqdv SR7V4mc+/OH7F8H/spH4frJRW/sd5WM0RKa9jGbdAjJcefpjo9kWkFd40mjvU+KD4mL18F pBJ+PtHPAOkFvQrTIZ8AgizhNlXtNLAotcK/gRkWzJAFbkn+y3GHqIlFH3mOUs2d/p4DGF T0eFtfRgGklmovCLvQJPjP7xXyyQrw0YuG1azaufSji8hUZWyawcbPABAzropO5pBwFYGm Ab+EvZnIHcOhOuiUcYBqyg0xW5a0dF62L36UdhM/rse9DOPwBxnymSFdAjOkAw== Content-Type: text/plain; charset=UTF-8 Cc: , , , , , , , , , , , X-Original-From: Li Zhe Content-Transfer-Encoding: 7bit X-Mailer: git-send-email 2.45.2 References: To: Date: Tue, 13 Jan 2026 14:37:36 +0800 Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism Message-Id: <20260113063736.29694-1-lizhe.67@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 From: "Li Zhe" In-Reply-To: X-Lms-Return-Path: On Mon, 12 Jan 2026 20:52:12 +0100, david@kernel.org wrote: > > As for concern (4), I believe it is orthogonal to this patchset, and > > the cover letter already contains a performance comparison that > > demonstrates the additional benefit. > > > >> I did see some comments in [1] about QEMU supporting user-mode > >> parallel zero-page operations; I'm just not sure what the current > >> state of that support looks like, or what the corresponding benchmark > >> numbers are. > > > > As noted above, QEMU already employs a parallel page-touch mechanism, > > yet the elapsed time remains noticeable. I am not deeply familiar with > > QEMU; please correct me if I am mistaken. > > I implemented some part of the parallel preallocation support in QEMU. > > With QEMU, you can specify the number of threads and even specify the > NUMA-placement of these threads. So you can pretty much fine-tune that > for an environment. > > You still pre-zero all hugetlb pages at VM startup time, just in > parallel though. So you pay some price at APP startup time. Hi David, Thank you for the comprehensive explanation. You are absolutely correct: QEMU's parallel preallocation is performed only during VM start-up. We submitted this patch series mainly because we observed that, even with the existing parallel mechanism, launching large-size VMs still incurs prohibitive delays. (Bringing up a 2 TB VM still requires more than 40 seconds for zeroing) > If you know that you will run such a VM (or something else) later, you > could pre-zero the memory from user space by using a hugetlb-backed file > and supplying that to QEMU as memory backend for the VM. Then, you can > start your VM without any pre-zeroing. > > I guess that approach should work universally. Of course, there are > limitations, as you would have to know how much memory an app needs, and > have a way to supply that memory in form of a file to that app. Regarding user-space pre-zeroing, I agree that it is feasible once the VM's memory footprint is known. We evaluated this approach internally; however, in production environments, it is almost impossible to predict the exact amount of memory a VM will require. Thanks, Zhe