Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp100503imu; Tue, 8 Jan 2019 15:28:35 -0800 (PST) X-Google-Smtp-Source: ALg8bN5PkekRFQ3oGaAe2Wghwo6rYAdjokYkbuLi2cOgXGC1OYAoWT+CeZmmuxPkneJKRRveukUF X-Received: by 2002:a17:902:f091:: with SMTP id go17mr3828034plb.235.1546990115261; Tue, 08 Jan 2019 15:28:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546990115; cv=none; d=google.com; s=arc-20160816; b=ur6aCcu7BsBWHoBDy2T/UZqEloIdh2HSogi2FaEHYKJ5lfKQq1+Rry3X+sXB7XEd19 Z6OJppyydc7/27Qvzqg8rHE8AU2vvt+tIkuWsQLrDV6QnFL8qEXZXRp0LDY7wSUx7CVe TGr9B+DVxz5ORNLX5kS2plfZTbrWy5WnM3aKmm0UohzfDOsWcSapUJBq6BCwYxQKxCMD 5xSacCTf57EGLX1VosibLaQKzZYGMtN7fBYch3+q3/C41THshX5GIcUQilJbbljXK0oD I9balYHc6k6hOy+FL7HL/ua4ciALar/Xjx0naxKRJVj5CJk7YkRlrp2liPlQLr7gA/fn xx5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=QYVsKcwU2s9ANcZb5pVug3XLlH99pKE/CIMyivuOmvY=; b=jMS/tqmavdogHx9vJTCshGzfQlGPX/Z0p3keZZ5/RIl9UL4FZ71nHFo4DqFtjbdHlE xDib1+L6lexAUx/QclsrKzqla3YYeMQ28Ly2BGOD8LTK5HIACHFqYsFu3lBg3uZD1q+L dblfw9Y1lR5K2bQr/dtBHqVYlBLVb2MpGUodSn3q5NrcVV9+hKIzHj/QJythdzGgoVrG GpTpuDRdU3jhGRB1HqqUpwn9qKCKfVWn0OXr8SatJ6K4xDrrbNtGfVWXZit4m+Xzy7+m 7hr9XJ0sdeMuEL/pqK4Wc1GzGOm8QKE8A2liSbQ9E+eTBtnKVXH5nb/1MX8m4J+7SWi6 xtjA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j29si7742447pga.550.2019.01.08.15.28.16; Tue, 08 Jan 2019 15:28:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731123AbfAHT40 (ORCPT + 99 others); Tue, 8 Jan 2019 14:56:26 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:50370 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730147AbfAHT4W (ORCPT ); Tue, 8 Jan 2019 14:56:22 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.8.65]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 5BD60891; Tue, 8 Jan 2019 19:56:21 +0000 (UTC) Date: Tue, 8 Jan 2019 11:56:20 -0800 From: Andrew Morton To: "Aneesh Kumar K.V" Cc: Michal Hocko , Alexey Kardashevskiy , David Gibson , Andrea Arcangeli , mpe@ellerman.id.au, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH V6 0/4] mm/kvm/vfio/ppc64: Migrate compound pages out of CMA region Message-Id: <20190108115620.6ec22e7d60b86d5f609d5a87@linux-foundation.org> In-Reply-To: <20190108045110.28597-1-aneesh.kumar@linux.ibm.com> References: <20190108045110.28597-1-aneesh.kumar@linux.ibm.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Jan 2019 10:21:06 +0530 "Aneesh Kumar K.V" wrote: > ppc64 use CMA area for the allocation of guest page table (hash page table). We won't > be able to start guest if we fail to allocate hash page table. We have observed > hash table allocation failure because we failed to migrate pages out of CMA region > because they were pinned. This happen when we are using VFIO. VFIO on ppc64 pins > the entire guest RAM. If the guest RAM pages get allocated out of CMA region, we > won't be able to migrate those pages. The pages are also pinned for the lifetime of the > guest. > > Currently we support migration of non-compound pages. With THP and with the addition of > hugetlb migration we can end up allocating compound pages from CMA region. This > patch series add support for migrating compound pages. The first path adds the helper > get_user_pages_cma_migrate() which pin the page making sure we migrate them out of > CMA region before incrementing the reference count. Does this code do anything for architectures other than powerpc? If not, should we be adding the ifdefs to avoid burdening other architectures with unused code?