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.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 E9080C433E1 for ; Mon, 17 Aug 2020 16:30:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A196C205CB for ; Mon, 17 Aug 2020 16:30:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="uNJT6bMf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A196C205CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0BE066B000A; Mon, 17 Aug 2020 12:30:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 06FA66B0010; Mon, 17 Aug 2020 12:30:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC6486B0022; Mon, 17 Aug 2020 12:30:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0201.hostedemail.com [216.40.44.201]) by kanga.kvack.org (Postfix) with ESMTP id D450C6B000A for ; Mon, 17 Aug 2020 12:30:23 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 899D42C79 for ; Mon, 17 Aug 2020 16:30:23 +0000 (UTC) X-FDA: 77160598326.06.arm20_4204fd027018 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id 52137100553E9 for ; Mon, 17 Aug 2020 16:30:23 +0000 (UTC) X-HE-Tag: arm20_4204fd027018 X-Filterd-Recvd-Size: 6852 Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 17 Aug 2020 16:30:22 +0000 (UTC) Received: by mail-pf1-f194.google.com with SMTP id u128so8481449pfb.6 for ; Mon, 17 Aug 2020 09:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vJQWoARBHQCrK/H5dQHqw1gZy4GLnGoyRENERvZRwMY=; b=uNJT6bMfAvwz5w0RbIZ22c/x3fxFtM2srKIIQVzA0Z7VF1GscUySz+F+oqeij9Q/Xz VnPDeKUyxKNOPtTkYcbbN2Sf5l9qeJka8yz/0IvnEeytAielHoVKy0it/V4H0TYqlnDp TvyBdZp0tHFefEjEXa/Thf4EvHNarpqWWCtSheMiQnPjQI0N8szCWIetaPD/8oVO19/i 1iLjsgUqED6uM6rY7PRtpehcvC76jXggM7/oYWzToGNswuOi/qjRGscRqK5BZl7N+z6O jQtugpN8PGw04sC4YSybvSMLzjTSXyMhciguD9PIGeFekx1tI5zRSIwM3WbSUHpbxWii O4lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=vJQWoARBHQCrK/H5dQHqw1gZy4GLnGoyRENERvZRwMY=; b=KFs8GaQ1nZw54NiWgL2TBLHJiN7MqXHEILvl4XaiSeg/VyPEBarR1G6tN1JCJ6Xo9I WTRI6CgqcjaU+uQBpEpxsKKfIXqIFGHiV/KaX43subaYZF6Xoa8e8a6meC0hinAei/YB yC8ncd28xgDN+XPcDYVRSQADSa24VjVTwD0/oh6FnKA9Tiq6bpt4+CpihD/7YeqD3N3H ji1taMecr/KwAP2CyvH5Yw8NIibNAbRTu2MsRPBepvmTRfEqgs0o8V/pcXcXnerWpgzW d4+UpZDEeECL5/YMTzIyLIYuTmwulgla8kVxX1oQnpxYA2lBW/+8h3+XW6/7nYZGB4Tq xgPw== X-Gm-Message-State: AOAM531B9PNfBAPAoRGaEiiB6xljjAbwZtIlX+C5DLq1l4xSKWTIT/16 7Rk+huz0GelZB8qUXFHOq8Q= X-Google-Smtp-Source: ABdhPJwUnWCpbsYYObZUpmVBqAG6gJBzIPfnveaB2mfaThdGb233ms4dfXABX7bRlD1g+icQmBSjCA== X-Received: by 2002:aa7:96b0:: with SMTP id g16mr12278149pfk.19.1597681821779; Mon, 17 Aug 2020 09:30:21 -0700 (PDT) Received: from google.com ([2620:15c:211:1:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id k21sm18087976pgl.0.2020.08.17.09.30.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Aug 2020 09:30:20 -0700 (PDT) Date: Mon, 17 Aug 2020 09:30:18 -0700 From: Minchan Kim To: David Hildenbrand Cc: Andrew Morton , linux-mm , Joonsoo Kim , Vlastimil Babka , John Dias , Suren Baghdasaryan , pullip.cho@samsung.com Subject: Re: [RFC 0/7] Support high-order page bulk allocation Message-ID: <20200817163018.GC3852332@google.com> References: <20200814173131.2803002-1-minchan@kernel.org> <4e2bd095-b693-9fed-40e0-ab538ec09aaa@redhat.com> <20200817152706.GB3852332@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 52137100553E9 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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 Mon, Aug 17, 2020 at 05:45:59PM +0200, David Hildenbrand wrote: > On 17.08.20 17:27, Minchan Kim wrote: > > On Sun, Aug 16, 2020 at 02:31:22PM +0200, David Hildenbrand wrote: > >> On 14.08.20 19:31, Minchan Kim wrote: > >>> There is a need for special HW to require bulk allocation of > >>> high-order pages. For example, 4800 * order-4 pages. > >>> > >>> To meet the requirement, a option is using CMA area because > >>> page allocator with compaction under memory pressure is > >>> easily failed to meet the requirement and too slow for 4800 > >>> times. However, CMA has also the following drawbacks: > >>> > >>> * 4800 of order-4 * cma_alloc is too slow > >>> > >>> To avoid the slowness, we could try to allocate 300M contiguous > >>> memory once and then split them into order-4 chunks. > >>> The problem of this approach is CMA allocation fails one of the > >>> pages in those range couldn't migrate out, which happens easily > >>> with fs write under memory pressure. > >> > >> Why not chose a value in between? Like try to allocate MAX_ORDER - 1 > >> chunks and split them. That would already heavily reduce the call frequency. > > > > I think you meant this: > > > > alloc_pages(GFP_KERNEL|__GFP_NOWARN, MAX_ORDER - 1) > > > > It would work if system has lots of non-fragmented free memory. > > However, once they are fragmented, it doesn't work. That's why we have > > seen even order-4 allocation failure in the field easily and that's why > > CMA was there. > > > > CMA has more logics to isolate the memory during allocation/freeing as > > well as fragmentation avoidance so that it has less chance to be stealed > > from others and increase high success ratio. That's why I want this API > > to be used with CMA or movable zone. > > I was talking about doing MAX_ORDER - 1 CMA allocations instead of one > big 300M allocation. As you correctly note, memory placed into CMA > should be movable, except for (short/long) term pinnings. In these > cases, doing allocations smaller than 300M and splitting them up should > be good enough to reduce the call frequency, no? I should have written that. The 300M I mentioned is really minimum size. In some scenraio, we need way bigger than 300M, up to several GB. Furthermore, the demand would be increased in near future. > > > > > A usecase is device can set a exclusive CMA area up when system boots. > > When device needs 4800 * order-4 pages, it could call this bulk against > > of the area so that it could effectively be guaranteed to allocate > > enough fast. > > Just wondering > > a) Why does it have to be fast? That's because it's related to application latency, which ends up user feel bad. > b) Why does it need that many order-4 pages? It's HW requirement. I couldn't say much about that. > c) How dynamic is the device need at runtime? Whenever the application launched. It depends on user's usage pattern. > d) Would it be reasonable in your setup to mark a CMA region in a way > such that it will never be used for other (movable) allocations, I don't get your point. If we don't want the area to used up for other movable allocation, why should we use it as CMA first? It sounds like reserved memory and just wasted the memory. Please clarify if I misudersoold your suggestion. > guaranteeing that you can immediately allocate it? Something like, > reserving a region during boot you know you'll immediately need later > completely for a device? > > > -- > Thanks, > > David / dhildenb >