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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham 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 9B0AEC5CFE7 for ; Wed, 11 Jul 2018 16:24:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4CE00205F4 for ; Wed, 11 Jul 2018 16:24:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="G1GTUJxy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CE00205F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389720AbeGKQ3L (ORCPT ); Wed, 11 Jul 2018 12:29:11 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:38667 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732562AbeGKQ3L (ORCPT ); Wed, 11 Jul 2018 12:29:11 -0400 Received: by mail-io0-f194.google.com with SMTP id v26-v6so24280167iog.5; Wed, 11 Jul 2018 09:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jQhK7aMYwOJcP384jjq95zp1W37FyYTsc8gDYxtT7MI=; b=G1GTUJxySvTBkuSL2pCsMcae2n3I8NZmaTtll7VqItvfPYyrPHntu+Dws9tpL1uch1 LQUxSe2XIUuRY7zUja5pP3wCCvo+KZXIYgZKu/503/Z6GkpjsUBUHTe0tyLOfoRR12HJ iuRCsDsagP5NBpPaf1rRkEhnvNpkqCVO8GFrc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jQhK7aMYwOJcP384jjq95zp1W37FyYTsc8gDYxtT7MI=; b=e6dU3zqStn+oH5oJfPyamZd2rYdt2qYQlvF08uNUcIUFyZKT9G7fCHfqQPfT9mZuGd wnnEwVvww2MOW+PfEIXDiH9fTZCv3liYT9tkk599qGfML1VsxrYnQVBKO6n+NPYHa8NH aEB9fF9lVV2+rxrQe0ng8XyArwxqPjNkqHPy5OhlrQA5dgUlS83ARAUdctpMRsomE1vO gOakpRk5wT9MUVpYy+tX9in2QbfJJMHpv30HrVOQ5fDDHyf1nM3vyfcQ0JSgrhH/XvpX LmZ2UugmlGE6iQD5R9KLCqgqDyk2Tw+w84I5SaQp9rrzO/jMaaup5cht8PC8HdhT+Vfb 5pCA== X-Gm-Message-State: AOUpUlGoM4q/z6/TdJ1O3F2T69YdGLyVWYPtz1upv4uNBxh4L8hYDkYY CE25FbyhigOTPPvrzqAYWHDY6QgWuMpeCsueTbJTbfMo X-Google-Smtp-Source: AAOMgpfWnlbHGYOTUqdkfOdRCyA/JLVfxS/CCJI4OTtFPu3LCjI7hfSRehbn9ElJLcjoywk7EhRUGKmPgJcUDn8ArxA= X-Received: by 2002:a6b:6b08:: with SMTP id g8-v6mr17706ioc.307.1531326245208; Wed, 11 Jul 2018 09:24:05 -0700 (PDT) MIME-Version: 1.0 References: <1531215067-35472-1-git-send-email-wei.w.wang@intel.com> <1531215067-35472-2-git-send-email-wei.w.wang@intel.com> <5B455D50.90902@intel.com> <20180711092152.GE20050@dhcp22.suse.cz> In-Reply-To: <20180711092152.GE20050@dhcp22.suse.cz> From: Linus Torvalds Date: Wed, 11 Jul 2018 09:23:54 -0700 Message-ID: Subject: Re: [PATCH v35 1/5] mm: support to get hints of free page blocks To: Michal Hocko Cc: wei.w.wang@intel.com, virtio-dev@lists.oasis-open.org, Linux Kernel Mailing List , virtualization , KVM list , linux-mm , "Michael S. Tsirkin" , Andrew Morton , Paolo Bonzini , liliang.opensource@gmail.com, yang.zhang.wz@gmail.com, quan.xu0@gmail.com, nilal@redhat.com, Rik van Riel , peterx@redhat.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 11, 2018 at 2:21 AM Michal Hocko wrote: > > We already have an interface for that. alloc_pages(GFP_NOWAIT, MAX_ORDER -1). > So why do we need any array based interface? That was actually my original argument in the original thread - that the only new interface people might want is one that just tells how many of those MAX_ORDER-1 pages there are. See the thread in v33 with the subject "[PATCH v33 1/4] mm: add a function to get free page blocks" and look for me suggesting just using #define GFP_MINFLAGS (__GFP_NORETRY | __GFP_NOWARN | __GFP_THISNODE | __GFP_NOMEMALLOC) struct page *page = alloc_pages(GFP_MINFLAGS, MAX_ORDER-1); for this all. But I could also see an argument for "allocate N pages of size MAX_ORDER-1", with some small N, simply because I can see the advantage of not taking and releasing the locking and looking up the zone individually N times. If you want to get gigabytes of memory (or terabytes), doing it in bigger chunks than one single maximum-sized page sounds fairly reasonable. I just don't think that "thousands of pages" is reasonable. But "tens of max-sized pages" sounds fair enough to me, and it would certainly not be a pain for the VM. So I'm open to new interfaces. I just want those new interfaces to make sense, and be low latency and simple for the VM to do. I'm objecting to the incredibly baroque and heavy-weight one that can return near-infinite amounts of memory. The real advantage of jjuist the existing "alloc_pages()" model is that I think the ballooning people can use that to *test* things out. If it turns out that taking and releasing the VM locks is a big cost, we can see if a batch interface that allows you to get tens of pages at the same time is worth it. So yes, I'd suggest starting with just the existing alloc_pages. Maybe it's not enough, but it should be good enough for testing. Linus