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=-2.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 76606C433DF for ; Fri, 14 Aug 2020 20:56:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 30BAB2074D for ; Fri, 14 Aug 2020 20:56:04 +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="iearmPmd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 30BAB2074D 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 AF5E06B000A; Fri, 14 Aug 2020 16:56:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA6E66B000C; Fri, 14 Aug 2020 16:56:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BBD06B000D; Fri, 14 Aug 2020 16:56:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 874E66B000A for ; Fri, 14 Aug 2020 16:56:03 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 39D1F5850 for ; Fri, 14 Aug 2020 20:56:03 +0000 (UTC) X-FDA: 77150381406.21.loss93_010ca6526fff Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 0849E180442C0 for ; Fri, 14 Aug 2020 20:56:03 +0000 (UTC) X-HE-Tag: loss93_010ca6526fff X-Filterd-Recvd-Size: 4811 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Fri, 14 Aug 2020 20:56:02 +0000 (UTC) Received: by mail-pl1-f193.google.com with SMTP id y10so3151879plr.11 for ; Fri, 14 Aug 2020 13:56:02 -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=CnsZ/dbCnWyWM+gyjva1gSJsf6zC3UCeBcW/irITfGU=; b=iearmPmd9LaBNtbXkN+w7ctt0ryyfCzJqgcwU9gS6utLU0jPxtBOZublewUgBE7I/t JiDNQcDpGrduBO5zsifUTLw70tseL+ZhNm/uOdMP8wQSr0OJQ1Qi+iQifgHAd9yrK3Ob 7j5MePZIjE7aXytSTWGJHfT5HllLvbc8diBa7RWNpyB91oyi1+AlEdrb3TLQuPpIfSjf wijyJS1/EFmXbqfOfulFFXgpMcDOoESkujacGe4z6H7Z+FvUgk84Bk5G4uv8S4ylAJtJ K5Ta2kg4KODMlOWu5UA8xS9zz7A9gzqibhGBNyHJbdjmb603M76xjZM9LTd8N5h9XsVO LENw== 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=CnsZ/dbCnWyWM+gyjva1gSJsf6zC3UCeBcW/irITfGU=; b=MVAyX+YkMrPWQuuQBXCBhq+4zfIre4HGiNeU5gEkOzbUVFw21HpV9nLccJSP8U/Sdk OiQrX6BgwaPW+OQjBpIdtY33Ty0xrgu51yL69SKteg9zmzsVIfI1ZYnoeh7n0V+TBsI0 bqoPT579IrapxUbwv/Bgi7LRfLznG8cYsN68GeXymq0538qogNfT5t6HDy8MZWMIpXBY adj1AYEqu4wCjVBqU+zT30SXFa/9OK0e0NtuyYjd2BXp52JyIvPm1BpG00otdBDSTXOr iGnKb8Ft+PFMcqQGrds6nOMmxsXv3+3nfWJXra06tQD0ZvqpmJLh6Ly+Flx/SEIJtx1c LCNw== X-Gm-Message-State: AOAM530in8Rovj7ukcEtuzgqTD9OZjLVnlRfMyO/slwWKe0HlLIZsynw XI0GNuL8qL3UYa6IO9ZlnBY= X-Google-Smtp-Source: ABdhPJxgyoUgTXCIdFuvslKHzqyQ2+1IhDHZrFEeycJLkn/uPJbdD1/C4r36TunkfhW3BD0txUPOQg== X-Received: by 2002:a17:90a:6d96:: with SMTP id a22mr3491262pjk.165.1597438561446; Fri, 14 Aug 2020 13:56:01 -0700 (PDT) Received: from google.com ([2620:15c:211:1:7220:84ff:fe09:5e58]) by smtp.gmail.com with ESMTPSA id b15sm9016534pgk.14.2020.08.14.13.55.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2020 13:56:00 -0700 (PDT) Date: Fri, 14 Aug 2020 13:55:58 -0700 From: Minchan Kim To: Matthew Wilcox 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: <20200814205558.GA2814941@google.com> References: <20200814173131.2803002-1-minchan@kernel.org> <20200814174020.GX17456@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200814174020.GX17456@casper.infradead.org> X-Rspamd-Queue-Id: 0849E180442C0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001113, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 14, 2020 at 06:40:20PM +0100, Matthew Wilcox wrote: > On Fri, Aug 14, 2020 at 10:31:24AM -0700, Minchan Kim wrote: > > There is a need for special HW to require bulk allocation of > > high-order pages. For example, 4800 * order-4 pages. > > ... but you haven't shown that user. Kyoungho is working on it. I am not sure how much he could share but hopefully, he could show some. Kyoungho? > > > int alloc_pages_bulk(unsigned long start, unsigned long end, > > unsigned int migratetype, gfp_t gfp_mask, > > unsigned int order, unsigned int nr_elem, > > struct page **pages); > > > > It will investigate the [start, end) and migrate movable pages > > out there by best effort(by upcoming patches) to make requested > > order's free pages. > > > > The allocated pages will be returned using pages parameter. > > Return value represents how many of requested order pages we got. > > It could be less than user requested by nr_elem. > > I don't understand why a user would need to know the PFNs to allocate > between. This seems like something that's usually specified by GFP_DMA32 > or similar. I wanted to let the API wok from CMA area and/or movable zone where are always fulled with migrable pages. If we carry on only zone flags without pfn range, it couldn't fulfil cma area cases. Other reason is if user see fewer pages returned, he could try subsequent ranges to get remained ones. > Is it useful to return fewer pages than requested? It's useful because user could ask further than what they need or retry.