Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2796939pxb; Tue, 9 Mar 2021 11:04:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJx0GmpHY/mD056Z3IByzEdU6/RIs1qgZN4t2JpzIdNf3eRs5iUq6bzaaCJ6rm7ye2d5onnG X-Received: by 2002:a17:906:bd2:: with SMTP id y18mr22255956ejg.482.1615316646100; Tue, 09 Mar 2021 11:04:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615316646; cv=none; d=google.com; s=arc-20160816; b=eZZzHsJr8BZVZ0374UyyK6CzH33vG4l8/vqFxETQ5OI5LylvUX5SjPna9rZbRO9EHR BKFvReCHizhZzxkNF5SiVW0WLZD8zWmfPN4sUWGCoAxAcods6Asb+wmKCEyRiD5QYFLs cZAw9sP8pe6ybl3KEx/5vTYQ5NYjxIq/1Wh79+EvkVaIqFSIZI+7xdtHG6TWi/arAQlt fCAGY2f1xzREHg387haCV1rGyLXFltJHldQK/IAKnXYvaXLzzYBM3QtF/Gerb3HCskK/ JLnqDD6o+0h+r6LB2LRkrNYnzR9wTPGJ4m+exgAi8XcwE8dxpy1RPuRev3wOgALco3TU iH1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:dkim-signature; bh=JIbVIf9JgfgLSsPGEjdt6SxaKG5D+REVg0Jf8YIfVe8=; b=fLkqPvzds1Tv/JE3Rb8L4b5RDig9QqtZYubm5PlJxG61hC4VmPMNbFf1p2UgC+/MnV vqyhbexKdtvmeJHB3s7LwuntV2r1L/iwOPexFn4KYTMLHHiUmSGoja/DsAp0/nb1Szx7 LptfgHLNUFVKhmjlE2bBWYzlTyfc2mDwefinQMZVJyDbb/7wCC7m4DrGnc6Pit1SJf2y VglmM7VPZbXrQLaVdtok+nff1R1PVdMu5ALPgp+F8XLveoR/BgTLoC9PO7Bc1Rd6p3Z5 vmm9lhxMdmnO8ysZ1swCcGz6p7ufmgwUehZa/gTP1ZVE6hw84iwRn5VvKW4YcB902m1w HfHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UJ3RUbIz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id os24si10345006ejb.729.2021.03.09.11.03.43; Tue, 09 Mar 2021 11:04:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UJ3RUbIz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230525AbhCITCA (ORCPT + 99 others); Tue, 9 Mar 2021 14:02:00 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:56720 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229916AbhCITBi (ORCPT ); Tue, 9 Mar 2021 14:01:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615316497; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JIbVIf9JgfgLSsPGEjdt6SxaKG5D+REVg0Jf8YIfVe8=; b=UJ3RUbIzk+V51YQAmJHoYEdI07ytzPDGxzwDj+c9YQy4SElGrT2W5scIzU+ppDwbivqq79 tVUgYNhsK3E8ckvI4QFDcV+QtE3sH6nniQvg9itflivjCnusXELuUim0j3/nXPbvLee9Y/ 3+f8d9VOFmOe5efAWYOAgZrIn10u4vY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-488-S_x2j83NOwmjLJUpsZSR-A-1; Tue, 09 Mar 2021 14:01:34 -0500 X-MC-Unique: S_x2j83NOwmjLJUpsZSR-A-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6113A26869; Tue, 9 Mar 2021 19:01:32 +0000 (UTC) Received: from [10.36.114.143] (ovpn-114-143.ams2.redhat.com [10.36.114.143]) by smtp.corp.redhat.com (Postfix) with ESMTP id AF04760C13; Tue, 9 Mar 2021 19:01:30 +0000 (UTC) Subject: Re: [RFC PATCH 0/3] hugetlb: add demote/split page functionality To: Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Michal Hocko , Oscar Salvador , Zi Yan , David Rientjes , Andrew Morton References: <20210309001855.142453-1-mike.kravetz@oracle.com> <29cb78c5-4fca-0f0a-c603-0c75f9f50d05@redhat.com> <6c66c265-c9b9-ffe9-f860-f96f3485477e@redhat.com> <777d3771-7d2f-8e88-8496-56440e195a43@oracle.com> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Tue, 9 Mar 2021 20:01:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <777d3771-7d2f-8e88-8496-56440e195a43@oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I need to take a close look at Oscar's patches. Too many thing to look > at/review :) > > This series does take into account gigantic pages allocated in CMA. > Such pages can be demoted, and we need to track that they need to go > back to CMA. Nothing super special for this, mostly a new hugetlb > specific flag to track such pages. Ah, just spotted it - patch #2 :) Took me a while to figure out that we end up calling cma_declare_contiguous_nid() with order_per_bit=0 - would have thought we would be using the actual smallest allocation order we end up using for huge/gigantic pages via CMA. Well, this way it "simply works". -- Thanks, David / dhildenb