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=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 E1076C433E1 for ; Wed, 19 Aug 2020 00:27:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 713A220772 for ; Wed, 19 Aug 2020 00:27:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KE9J6OAx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 713A220772 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 47EEC8D000B; Tue, 18 Aug 2020 20:27:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4312F8D0008; Tue, 18 Aug 2020 20:27:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 346018D000B; Tue, 18 Aug 2020 20:27:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0005.hostedemail.com [216.40.44.5]) by kanga.kvack.org (Postfix) with ESMTP id 1BE2A8D0008 for ; Tue, 18 Aug 2020 20:27:35 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C7A821F0A for ; Wed, 19 Aug 2020 00:27:34 +0000 (UTC) X-FDA: 77165429628.08.dogs85_1f0845927023 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 9DB721819E798 for ; Wed, 19 Aug 2020 00:27:34 +0000 (UTC) X-HE-Tag: dogs85_1f0845927023 X-Filterd-Recvd-Size: 5543 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Wed, 19 Aug 2020 00:27:34 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id cq28so16695408edb.10 for ; Tue, 18 Aug 2020 17:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m4680ylSYw1hHb95sCBxE3pupWdBgs/VPNuxT2f52jo=; b=KE9J6OAxY08WS66RgBT5HZ8s0h6zDkbSZV/IHo33n1TwjRZf+VNe4+36JT5VLSrOt6 HylvQdrhCiXhtvxO2ivY7wm+Emkosv42DIY5+s6MZ6HzCXBoKjVOd7tLcf5PD10cvU8o jVy6TcN0AcjNX5TXVS8kxb1cs7ejmQe82GfcRDEnJoTzSyKVPNsPhJeT5NHPL+0Vp0Hu 1xlNtZEW5PMp5cEyB7ezKtQCzT7dTXIT24R+KtDU+1rY0Z8ww13P/Blzjas+SaH7zbdR 22oDSG2SR3hfdIm2yaJv/U1OLJyhhKgEGsq6sUw+q07n3i5IuUGQEfjjrNXC690kC2w5 embA== 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=m4680ylSYw1hHb95sCBxE3pupWdBgs/VPNuxT2f52jo=; b=TT3Xx/P/mwjSz+nEkxvp0cI8J7C/BGkcfTA4rhUL7x5LDkb7UwD52ZgTh+L9NuUl23 jxF8SBvOheAYp+iHjrdiL0vvjbsIGo/SSLyHTt9PBZlLGlEvKNZtq1pKcKw9iLpFx3oO PPJIqWl/AuF0/AuRkQ8TWsgOWmUKQC7RIwdqrdgCl8dWJk+tufMvsVn4ZZgyl48KwX4M 3mWb33SGKB6uE9PgjsdWb0u4u8UOpjgxsIyNnFa9BuM0eZrAaY2BwYcJXERVeyZrly93 bI251reL1zx1oLstpW/tSXYUgsiyXhJ9pln+lmfB8Oy7ErGm8mTZbh2pwIF+uEdUVIDb BmNw== X-Gm-Message-State: AOAM53304HEJMw+fEM33knmKE2pHzBTuLYOtI0WSsumqzF5JRDFwhYk+ B5jtAms4ZVT0ML8Tt+0Av1YhlSLfplNq5mSZbmY= X-Google-Smtp-Source: ABdhPJzEmhumiGr6dJZ7BMkshiiACLMmtPa0AL5zZ4MfjcEBWhYjTqcBynE0xd16ID+NzagR3iz9/zZgWgCSE3hpPZA= X-Received: by 2002:a05:6402:1d92:: with SMTP id dk18mr21599222edb.206.1597796852913; Tue, 18 Aug 2020 17:27:32 -0700 (PDT) MIME-Version: 1.0 References: <20200814173131.2803002-1-minchan@kernel.org> <4e2bd095-b693-9fed-40e0-ab538ec09aaa@redhat.com> <20200817152706.GB3852332@google.com> <20200817163018.GC3852332@google.com> <20200817233442.GD3852332@google.com> <7c07e8cf-6adc-92be-d819-d60a389559d8@redhat.com> <20200818151543.GE3852332@google.com> <20200818155825.GS17456@casper.infradead.org> <2d835b0c-da48-52d1-1792-255bbad3425d@redhat.com> In-Reply-To: <2d835b0c-da48-52d1-1792-255bbad3425d@redhat.com> From: Yang Shi Date: Tue, 18 Aug 2020 17:27:20 -0700 Message-ID: Subject: Re: [RFC 0/7] Support high-order page bulk allocation To: David Hildenbrand Cc: Matthew Wilcox , Minchan Kim , Andrew Morton , linux-mm , Joonsoo Kim , Vlastimil Babka , John Dias , Suren Baghdasaryan , pullip.cho@samsung.com, Chris Goldsworthy , Nicholas Piggin Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 9DB721819E798 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Tue, Aug 18, 2020 at 9:22 AM David Hildenbrand wrote: > > On 18.08.20 17:58, Matthew Wilcox wrote: > > On Tue, Aug 18, 2020 at 08:15:43AM -0700, Minchan Kim wrote: > >> I understand pfn stuff in the API is not pretty but the concept of idea > >> makes sense to me in that go though the *migratable area* and get possible > >> order pages with hard effort. It looks like GFP_NORETRY version for > >> kmem_cache_alloc_bulk. > >> > >> How about this? > >> > >> int cma_alloc(struct cma *cma, int order, unsigned int nr_elem, struct page **pages); > > > > I think that makes a lot more sense as an API. Although I think you want > > > > int cma_bulk_alloc(struct cma *cma, unsigned order, unsigned nr_elem, > > struct page **pages); > > > > Right, and I would start with a very simple implementation that does not > mess with alloc_contig_range() (meaning: modify it). > > I'd then much rather want to see simple tweaks to alloc_contig_range() > to improve the situation. E.g., some kind of "fail fast" flag that let's > the caller specify to skip some draining (or do it manually in cma > before a bulk allocation) and rather fail fast than really trying to > allocate the range whatever it costs. Make sense to me. There are plenty such optimizations in mm, i.e. light async migration vs sync migration. And, it looks Minchan could accept allocation failure (return less than "elem" pages), then the user could just retry. > > There are multiple optimizations you can play with then (start with big > granularity and split, move to smaller granularity on demand, etc., all > nicely wrapped in cma_bulk_alloc()). > > Yes, it might not end up as fast as this big hack (sorry) here, but as > Nicholas correctly said, it's not our motivation to implement and > maintain such complexity just to squeeze the last milliseconds out of an > allocation path for "broken devices". > > I absolutely dislike pushing this very specific allocation policy down > to the core range allocator. It's already makes my head spin every time > I look at it in detail. > > -- > Thanks, > > David / dhildenb > >