From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B891BC35669 for ; Fri, 21 Feb 2020 22:08:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8CDE0208C4 for ; Fri, 21 Feb 2020 22:08:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="u9q1zQdY" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726826AbgBUWIS (ORCPT ); Fri, 21 Feb 2020 17:08:18 -0500 Received: from mail-pj1-f47.google.com ([209.85.216.47]:56223 "EHLO mail-pj1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726683AbgBUWIS (ORCPT ); Fri, 21 Feb 2020 17:08:18 -0500 Received: by mail-pj1-f47.google.com with SMTP id d5so1358918pjz.5 for ; Fri, 21 Feb 2020 14:08:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jNjBXjAdVCy5awvtdHoOypna1zj38J0pg8CQSdMcaDo=; b=u9q1zQdYJPKZ9WH5HewgltC6Opyxrtk0f1IEoD9S4k/3aRAlidhgR/JsnOSx0U7dap cpdYtH3g8KAud5TFgV/1Hv2f+EIwPSFOMuVjqL3sKrvfyIZEoXAXiPDcFCxyi3W0pvOh KS3gehjx5v7LCv3NJqk3ExEGTAMeblig3IotXjzLxQZwfyUMZTYk8RYaIhA/KVTOjRHg 9oXd6bN7OZOb0NalnKaioyHOfchao+AzLKfu++2LUH11KK8/cPiRuSgVXH94LfX5cCYz pm/og+X94CNO7HhgfJnNwjUPP4nEF8sAL4oGo2H1pM0P2+ucAEdg6mORjGGBcxBKxzZ9 hiyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=jNjBXjAdVCy5awvtdHoOypna1zj38J0pg8CQSdMcaDo=; b=CdP+tuofEmjNvTnVt1U979kEz9/e2RjAv14Vuk4bYaJMab6JXC6zPg40vE65ayNG+o CuSK0WRCaUJz3KWgpN86nCTUDx/xnZ3YO+kLngLfiloB4UAmndYNiDrVZ+4pOCi8GK9Q ieMaZOvQGV4+IhFVELT6dUF+bVkIRvuIUD5g5Qd7b4JqM7lgaBD8Ddgs0nOq8rFDz1i7 AVtogY5dd8LhlLtYrU+vBM3xoxkCy0cz4qzplIPIbNPrB9Oa0T1BxvqboZ9G6jQ17M9c aWjFvtvqkVq87k6kqGz+wWRGvv8K5X79ul/wNl28H3QgPPdHehWszdhaNJxjFw2tWdFc rSog== X-Gm-Message-State: APjAAAVgNnEGTClNHl1lx+AfjBpTXgkSv25One5DcklHi0iDKgMuVGrC opURwXNiTcp5WzAAQyRTEqXC6K52qufOujC4 X-Google-Smtp-Source: APXvYqwttH1vhpl3udu/KCeWv2UYptzXfNlDcvmcYzCt3xV2vaHF6IfqyEVN59jTbw75X+J5/mD4ig== X-Received: by 2002:a17:90b:8ce:: with SMTP id ds14mr5661172pjb.70.1582322897481; Fri, 21 Feb 2020 14:08:17 -0800 (PST) Received: from ?IPv6:2620:15c:2c1:101:8085:b46d:4651:575f? ([2620:15c:2c1:101:8085:b46d:4651:575f]) by smtp.gmail.com with ESMTPSA id x197sm3921588pfc.1.2020.02.21.14.08.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Feb 2020 14:08:16 -0800 (PST) Subject: Re: RFC: Split EPT huge pages in advance of dirty logging To: Ben Gardon , "Zhoujian (jay)" Cc: Peter Xu , "kvm@vger.kernel.org" , "qemu-devel@nongnu.org" , "pbonzini@redhat.com" , "dgilbert@redhat.com" , "quintela@redhat.com" , "Liujinsong (Paul)" , "linfeng (M)" , "wangxin (U)" , "Huangweidong (C)" , pfeiner@google.com References: <20200218174311.GE1408806@xz-x1> <20200219171919.GA34517@xz-x1> From: Junaid Shahid Organization: Google Message-ID: Date: Fri, 21 Feb 2020 14:08:14 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On 2/20/20 9:34 AM, Ben Gardon wrote: > > FWIW, we currently do this eager splitting at Google for live > migration. When the log-dirty-memory flag is set on a memslot we > eagerly split all pages in the slot down to 4k granularity. > As Jay said, this does not cause crippling lock contention because the > vCPU page faults generated by write protection / splitting can be > resolved in the fast page fault path without acquiring the MMU lock. > I believe +Junaid Shahid tried to upstream this approach at some point > in the past, but the patch set didn't make it in. (This was before my > time, so I'm hoping he has a link.) > I haven't done the analysis to know if eager splitting is more or less > efficient with parallel slow-path page faults, but it's definitely > faster under the MMU lock. > I am not sure if we ever posted those patches upstream. Peter Feiner would know for sure. One notable difference in what we do compared to the approach outlined by Jay is that we don't rely on tdp_page_fault() to do the splitting. So we don't have to create a dummy VCPU and the specialized split function is also much faster. Thanks, Junaid