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,FSL_HELO_FAKE,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 69863C64E7C for ; Wed, 2 Dec 2020 19:26:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9E2C922240 for ; Wed, 2 Dec 2020 19:26:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E2C922240 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 9B9586B0036; Wed, 2 Dec 2020 14:26:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 968506B005C; Wed, 2 Dec 2020 14:26:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 858116B005D; Wed, 2 Dec 2020 14:26:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0193.hostedemail.com [216.40.44.193]) by kanga.kvack.org (Postfix) with ESMTP id 6C6DF6B0036 for ; Wed, 2 Dec 2020 14:26:17 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 264701EE6 for ; Wed, 2 Dec 2020 19:26:17 +0000 (UTC) X-FDA: 77549323194.23.train34_5306eb3273b5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 072A637613 for ; Wed, 2 Dec 2020 19:26:17 +0000 (UTC) X-HE-Tag: train34_5306eb3273b5 X-Filterd-Recvd-Size: 8184 Received: from mail-pl1-f195.google.com (mail-pl1-f195.google.com [209.85.214.195]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Dec 2020 19:26:16 +0000 (UTC) Received: by mail-pl1-f195.google.com with SMTP id j1so131358pld.3 for ; Wed, 02 Dec 2020 11:26:16 -0800 (PST) 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=gpjxGYzLSyNarmAmbAQjfYVpd3J0HaJaIoHV/RbyoP0=; b=VaodmzoR9g7kj+trfPWTjKbOUGtif1gfK+MnyL7sDiLsjyPyv9Ozrs83cRZhE6sMsD B4rvR5ybl880Y58IX1cTIx/9xN995XcaDz2WforplB/T06qvrvmx8BerjEPT2F2vdfwQ Ossz0JVVbfsMH2GwekdB48BNH0Nq5/MPXAuAkPwkpLCSv9Zf7nMfkdixgZp5Cx66ZXCM yG7FuCrCsM02755Wnk1gKEi9cXAANCbuUPixXWf6wveszg2iZaK/MYobBJAYJlAjgmxa 62C0njYK1ROuxHembS4Qg5lX/pBT1Lcs4fh1ORKYWO6VEyQdVU5gcRDw6HMRe2kMGB1n UZaw== 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=gpjxGYzLSyNarmAmbAQjfYVpd3J0HaJaIoHV/RbyoP0=; b=m07KKWcsQQD4GPGd/iZ0TYp4UT+6bDTA6tux61lRWLEQyYSkAvdncXJYEzmDQnC1yx jcOmFp7a6CvDegGAOVCJhpjsHsk/ZUcfCHkPqggqhM2Px9QF93PksEXYmil3tGROacO3 PhOekHoKadKXUbMGdP4XM5GzLGkQ80sHjZhrlmL+QdZsRgrf7uUI5Du9eZ6YRpvDXLK3 W2/pUHr9gclExwG7BQLTXqhz3fj28N+uwo+UlI6PyExvHQBYtwGp6g4PrFhRt5hHl6A6 kfOR/rAQwZBhg8mEt+w5Ig8hcgcc5rmXvVZRER2WTzbG+EoWvEkkDlhlDr1pMsF1oZzi Yb9g== X-Gm-Message-State: AOAM531u60eiSQqCbfODsxK/F2TgZ+IVqV3UrgjDbnZTLlAJnKnEW4Wb nFcPo7Zrhfbm2h+o8E7k7W8= X-Google-Smtp-Source: ABdhPJxcdPTZ5uZMP8zvH4q1sui0DmS0RvpM84/fgaeUTS26506J8tp8Ce+fVMlFSti+TUz8UFLwqA== X-Received: by 2002:a17:90b:4a03:: with SMTP id kk3mr1260133pjb.97.1606937175483; Wed, 02 Dec 2020 11:26:15 -0800 (PST) Received: from google.com ([2620:15c:211:201:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id js9sm2652626pjb.2.2020.12.02.11.26.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Dec 2020 11:26:14 -0800 (PST) Date: Wed, 2 Dec 2020 11:26:11 -0800 From: Minchan Kim To: Michal Hocko Cc: David Hildenbrand , Andrew Morton , LKML , linux-mm , hyesoo.yu@samsung.com, willy@infradead.org, iamjoonsoo.kim@lge.com, vbabka@suse.cz, surenb@google.com, pullip.cho@samsung.com, joaodias@google.com, hridya@google.com, sumit.semwal@linaro.org, john.stultz@linaro.org, Brian.Starkey@arm.com, linux-media@vger.kernel.org, devicetree@vger.kernel.org, robh@kernel.org, christian.koenig@amd.com, linaro-mm-sig@lists.linaro.org Subject: Re: [PATCH v2 2/4] mm: introduce cma_alloc_bulk API Message-ID: References: <20201201175144.3996569-1-minchan@kernel.org> <20201201175144.3996569-3-minchan@kernel.org> <8f006a4a-c21d-9db3-5493-fb1cc651b0cf@redhat.com> <20201202154915.GU17338@dhcp22.suse.cz> <20201202164834.GV17338@dhcp22.suse.cz> <20201202185107.GW17338@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201202185107.GW17338@dhcp22.suse.cz> 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 Wed, Dec 02, 2020 at 07:51:07PM +0100, Michal Hocko wrote: > On Wed 02-12-20 09:54:29, Minchan Kim wrote: > > On Wed, Dec 02, 2020 at 05:48:34PM +0100, Michal Hocko wrote: > > > On Wed 02-12-20 08:15:49, Minchan Kim wrote: > > > > On Wed, Dec 02, 2020 at 04:49:15PM +0100, Michal Hocko wrote: > > > [...] > > > > > Well, what I can see is that this new interface is an antipatern to our > > > > > allocation routines. We tend to control allocations by gfp mask yet you > > > > > are introducing a bool parameter to make something faster... What that > > > > > really means is rather arbitrary. Would it make more sense to teach > > > > > cma_alloc resp. alloc_contig_range to recognize GFP_NOWAIT, GFP_NORETRY resp. > > > > > GFP_RETRY_MAYFAIL instead? > > > > > > > > If we use cma_alloc, that interface requires "allocate one big memory > > > > chunk". IOW, return value is just struct page and expected that the page > > > > is a big contiguos memory. That means it couldn't have a hole in the > > > > range. > > > > However the idea here, what we asked is much smaller chunk rather > > > > than a big contiguous memory so we could skip some of pages if they are > > > > randomly pinned(long-term/short-term whatever) and search other pages > > > > in the CMA area to avoid long stall. Thus, it couldn't work with exising > > > > cma_alloc API with simple gfp_mak. > > > > > > I really do not see that as something really alient to the cma_alloc > > > interface. All you should care about, really, is what size of the object > > > you want and how hard the system should try. If you have a problem with > > > an internal implementation of CMA and how it chooses a range and deal > > > with pinned pages then it should be addressed inside the CMA allocator. > > > I suspect that you are effectivelly trying to workaround those problems > > > by a side implementation with a slightly different API. Or maybe I still > > > do not follow the actual problem. > > > > > > > > I am not deeply familiar with the cma allocator so sorry for a > > > > > potentially stupid question. Why does a bulk interface performs better > > > > > than repeated calls to cma_alloc? Is this because a failure would help > > > > > to move on to the next pfn range while a repeated call would have to > > > > > deal with the same range? > > > > > > > > Yub, true with other overheads(e.g., migration retrial, waiting writeback > > > > PCP/LRU draining IPI) > > > > > > Why cannot this be implemented in the cma_alloc layer? I mean you can > > > cache failed cases and optimize the proper pfn range search. > > > > So do you suggest this? > > > > enum cma_alloc_mode { > > CMA_ALLOC_NORMAL, > > CMA_ALLOC_FAIL_FAST, > > }; > > > > struct page *cma_alloc(struct cma *cma, size_t count, unsigned int > > align, enum cma_alloc_mode mode); > > > > >From now on, cma_alloc will keep last failed pfn and then start to > > search from the next pfn for both CMA_ALLOC_NORMAL and > > CMA_ALLOC_FAIL_FAST if requested size from the cached pfn is okay > > within CMA area and then wraparound it couldn't find right pages > > from the cached pfn. Othewise, the cached pfn will reset to the zero > > so that it starts the search from the 0. I like the idea since it's > > general improvement, I think. > > Yes something like that. There are more options to be clever here - e.g. > track ranges etc. but I am not sure this is worth the complexity. Agree. Just last pfn caching would be good enough as simple start. > > > Furthemore, With CMA_ALLOC_FAIL_FAST, it could avoid several overheads > > at the cost of sacrificing allocation success ratio like GFP_NORETRY. > > I am still not sure a specific flag is a good interface. Really can this > be gfp_mask instead? I am not strong(even, I did it with GFP_NORETRY) but David wanted to have special mode and I agreed when he mentioned ALLOC_CONTIG_HARD as one of options in future(it would be hard to indicate that mode with gfp flags). > > > I think that would solve the issue with making the API more flexible. > > Before diving into it, I'd like to confirm we are on same page. > > Please correct me if I misunderstood. > > I am not sure you are still thinking about a bulk interface. No I am thinking of just using cma_alloc API with cached pfn as interal improvement and adding new fast fail mode to the API so driver could call the API repeatedly until then can get enough pages.