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=-4.0 required=3.0 tests=INCLUDES_PATCH, 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 4E81BC433E0 for ; Mon, 29 Jun 2020 07:55:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0FE8A20768 for ; Mon, 29 Jun 2020 07:55:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0FE8A20768 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 5FF7B6B0003; Mon, 29 Jun 2020 03:55:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AECC6B0005; Mon, 29 Jun 2020 03:55:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49CDB6B0006; Mon, 29 Jun 2020 03:55:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 3156B6B0003 for ; Mon, 29 Jun 2020 03:55:14 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BB36F824805A for ; Mon, 29 Jun 2020 07:55:13 +0000 (UTC) X-FDA: 76981488906.17.face00_560986626e6d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 94A99180D0180 for ; Mon, 29 Jun 2020 07:55:13 +0000 (UTC) X-HE-Tag: face00_560986626e6d X-Filterd-Recvd-Size: 5317 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 29 Jun 2020 07:55:13 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id z17so11989829edr.9 for ; Mon, 29 Jun 2020 00:55:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Go+MGAqswQJ5Or7swZG3YdRuz2dFng+SdQlnF5u8UcY=; b=WhOW/NtnH7XIyR0xnE50VGKSqvasyCYEhKYq1PZnWUFy5aUw9GnWBg4Seu2mIrAuAu d5h+FGJzJV0tP04AktegelfsvQ/ylWy6JPfRkMOPId3iw/g8/hf5qqBIXit3gy8VCMHb 6gXUD02qw8V2An+aPc4r0n3tG0xdwm7wpMxi5fJxKKD5Lb0BpJX/PX9n9vOSbklzAyz+ IL4uBWna6XhKzZX/4SriMK1BAXLuN8+u5Rm0CwXzP95srnOfAYY3rNagTVYRExIlE6Xi akNZVjq1Z/6MMVwEL7xDC4/NHNU3aoJx+JPXoWlQSfCtqUzXGpmnrcTz9j5MYuz+WCBU IryQ== X-Gm-Message-State: AOAM530Sd50oTY/tM92hjrHJhKD8tQto0Z85cQYpAf2gX9lxZZbtb2FQ 6myLM8l0cE6F0u4l6pBwYZI= X-Google-Smtp-Source: ABdhPJynPWVX63OFc/KJXdxkxNjTlQ3FASZvpIdqRrmIoYOiBcrDUVoghxouzfD/w2WirFe+O5AHNQ== X-Received: by 2002:a50:b086:: with SMTP id j6mr13392527edd.6.1593417312217; Mon, 29 Jun 2020 00:55:12 -0700 (PDT) Received: from localhost (ip-37-188-168-3.eurotel.cz. [37.188.168.3]) by smtp.gmail.com with ESMTPSA id g22sm2606486eds.67.2020.06.29.00.55.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2020 00:55:11 -0700 (PDT) Date: Mon, 29 Jun 2020 09:55:10 +0200 From: Michal Hocko To: Joonsoo Kim Cc: Andrew Morton , Linux Memory Management List , LKML , kernel-team@lge.com, Vlastimil Babka , Christoph Hellwig , Roman Gushchin , Mike Kravetz , Naoya Horiguchi , Joonsoo Kim Subject: Re: [PATCH v3 4/8] mm/hugetlb: make hugetlb migration callback CMA aware Message-ID: <20200629075510.GA32461@dhcp22.suse.cz> References: <1592892828-1934-1-git-send-email-iamjoonsoo.kim@lge.com> <1592892828-1934-5-git-send-email-iamjoonsoo.kim@lge.com> <20200625115422.GE1320@dhcp22.suse.cz> <20200626072324.GT1320@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 94A99180D0180 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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 29-06-20 15:27:25, Joonsoo Kim wrote: [...] > Solution that Introduces a new > argument doesn't cause this problem while avoiding CMA regions. My primary argument is that there is no real reason to treat hugetlb dequeing somehow differently. So if we simply exclude __GFP_MOVABLE for _any_ other allocation then this certainly has some drawbacks on the usable memory for the migration target and it can lead to allocation failures (especially on movable_node setups where the amount of movable memory might be really high) and therefore longterm gup failures. And yes those failures might be premature. But my point is that the behavior would be _consistent_. So a user wouldn't see random failures for some types of pages while a success for others. Let's have a look at this patch. It is simply working that around the restriction for a very limited types of pages - only hugetlb pages which have reserves in non-cma movable pools. I would claim that many setups will simply not have many (if any) spare hugetlb pages in the pool except for temporary time periods when a workload is (re)starting because this would be effectively a wasted memory. The patch is adding a special case flag to claim what the code already does by memalloc_nocma_{save,restore} API so the information is already there. Sorry I didn't bring this up earlier but I have completely forgot about its existence. With that one in place I do agree that dequeing needs a fixup but that should be something like the following instead. diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 57ece74e3aae..c1595b1d36f3 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1092,10 +1092,14 @@ static struct page *dequeue_huge_page_nodemask(struct hstate *h, gfp_t gfp_mask, /* Movability of hugepages depends on migration support. */ static inline gfp_t htlb_alloc_mask(struct hstate *h) { + gfp_t gfp; + if (hugepage_movable_supported(h)) - return GFP_HIGHUSER_MOVABLE; + gfp = GFP_HIGHUSER_MOVABLE; else - return GFP_HIGHUSER; + gfp = GFP_HIGHUSER; + + return current_gfp_context(gfp); } static struct page *dequeue_huge_page_vma(struct hstate *h, If we even fix this general issue for other allocations and allow a better CMA exclusion then it would be implemented consistently for everybody. Does this make more sense to you are we still not on the same page wrt to the actual problem? -- Michal Hocko SUSE Labs