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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 C1771C2BBFD for ; Mon, 13 Apr 2020 14:49:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 87E5A20732 for ; Mon, 13 Apr 2020 14:49:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="cRx3Izyt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 87E5A20732 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 20B828E011E; Mon, 13 Apr 2020 10:49:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BBD68E0104; Mon, 13 Apr 2020 10:49:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D2268E011E; Mon, 13 Apr 2020 10:49:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id E90C08E0104 for ; Mon, 13 Apr 2020 10:49:28 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 977F6180AD802 for ; Mon, 13 Apr 2020 14:49:28 +0000 (UTC) X-FDA: 76703115216.11.spot65_3592bb472e160 X-HE-Tag: spot65_3592bb472e160 X-Filterd-Recvd-Size: 4131 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Apr 2020 14:49:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586789367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uWFIUTP14rr06BBJf7/lRX/qB9hDoGM3irEGOnU8QDY=; b=cRx3IzytRfUY2PYTjnSuo9F6FfHNdJHdCDQtyroi1nuIM5t4FvqMvdIqqnHGeFh+DelB3C N36MDh4mltBUf4IHR9QtuQCGtMUzptaw5dMMONWw+uj8xUfAmzMemJiC/xRqJ2+G2EBFXB 7f/30zaw4oZnsBCoR8jk60UUhMq1rvg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-388-ucynfrusNL-k6vaR3IKi2Q-1; Mon, 13 Apr 2020 10:49:21 -0400 X-MC-Unique: ucynfrusNL-k6vaR3IKi2Q-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E6592DB63; Mon, 13 Apr 2020 14:49:19 +0000 (UTC) Received: from w520.home (ovpn-112-162.phx2.redhat.com [10.3.112.162]) by smtp.corp.redhat.com (Postfix) with ESMTP id 968A05C1B2; Mon, 13 Apr 2020 14:49:15 +0000 (UTC) Date: Mon, 13 Apr 2020 08:49:15 -0600 From: Alex Williamson To: Dave Hansen Cc: Alexander Duyck , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrea Arcangeli , Dan Williams , David Hildenbrand , Michal Hocko , Andrew Morton Subject: Re: [RFC PATCH 0/4] mm: Add PG_zero support Message-ID: <20200413084915.1bae0007@w520.home> In-Reply-To: References: <20200412090728.GA19572@open-light-1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sun, 12 Apr 2020 18:43:07 -0700 Dave Hansen wrote: > On 4/12/20 2:07 AM, liliangleo wrote: > > Zero out the page content usually happens when allocating pages, > > this is a time consuming operation, it makes pin and mlock > > operation very slowly, especially for a large batch of memory. > > > > This patch introduce a new feature for zero out pages before page > > allocation, it can help to speed up page allocation. > > I think the bar for getting something like this merged is going to be > pretty high. We have a long history of zeroing close to page use for > cache warmth reasons. Starting up big VMs which won't soon touch the > memory they are allocating is basically the most pathological case > against our approach since they don't *care* about cache warmth. > > I'm also not sure it's something we _want_ to optimize for. > > VFIO's unconditional page pinning is the real problem here IMNHO. They > don't *really* need to pin the memory. We just don't have good > paravirtualized IOMMU support or want to pay the runtime cost for > pin/unpin operations. You *could* totally have speedy VM startup if > only the pages being accessed or having DMA performed to them were > allocated. But, the hacks that are in place mean that everything must > be pinned. Maybe in an SEV or Secure Boot environment we can assume the VM guest OS uses the IOMMU exclusively for DMA, but otherwise the IOMMU is optional (at least for x86, other archs do require IOMMU support afaik). Therefore, how would we know which pages to pin when there are only limited configs where we might be able to lean on the vIOMMU to this extent? Thanks, Alex