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.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 93580C433FE for ; Fri, 4 Dec 2020 04:03:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F2966222B6 for ; Fri, 4 Dec 2020 04:03:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F2966222B6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CC3916B0036; Thu, 3 Dec 2020 23:03:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C7C976B005C; Thu, 3 Dec 2020 23:03:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B3A356B0068; Thu, 3 Dec 2020 23:03:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0070.hostedemail.com [216.40.44.70]) by kanga.kvack.org (Postfix) with ESMTP id 9A9936B0036 for ; Thu, 3 Dec 2020 23:03:08 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 62EF03631 for ; Fri, 4 Dec 2020 04:03:08 +0000 (UTC) X-FDA: 77554254456.28.goose59_6002513273c1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 4515D6D75 for ; Fri, 4 Dec 2020 04:03:08 +0000 (UTC) X-HE-Tag: goose59_6002513273c1 X-Filterd-Recvd-Size: 4905 Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Dec 2020 04:03:07 +0000 (UTC) Received: by mail-pg1-f195.google.com with SMTP id m9so2738051pgb.4 for ; Thu, 03 Dec 2020 20:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=7DSsMY7O9iqF1kwVjLuD2Y4xlHlq3Q1GYWL81Z4udlU=; b=Ill+Sh/d5qdK475EE+dKWx9gpK+E5fU5RzwnC82K6d7BmIGRdKNIqlwyvRmoDBxa5u g+YnvuqUTUEHcyJ3ydhc9E+p6+X06vjsGQQOav7zR1e+KPwytoMrneDRsYWBfauxnrMf I8wjSYAvgVgCsMrm6opvOV/hhurCGHjN4dmwKWyzhX47SIDjOae4DviuHqjEnemSNjmq YvzQz5J/nS9SS4iLgaz6d7xuk74fOv0cIakUM3fC3rHbCNT9YveV4kR0O1lMS8DVHCDU QXcVCmClKWGWWIQy4kYkPWZfOTWnXcszTKevrsIq42+pI4oYiMD0CpAmBV+lOZ70gqKC T/4w== 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:user-agent; bh=7DSsMY7O9iqF1kwVjLuD2Y4xlHlq3Q1GYWL81Z4udlU=; b=mvCeg8OOMp1gZa8XA31u7r90UufAv2MNBT5irVwulzkZJ5OrEl7PLzxTE/U+dCNRzk 46ho/yj7hlR8x7ArlmDVS8rMz+X1d0J/es+1R8UPg5dAAwd2HF5AM9wuTU/JvLV4BIqU qKrjXQ1Qd1dNH7ceTxMSLaGiHy3paR5LomX/XpENzXEf7ax5ISeews1ELENRhVh2U6BX Fh9OS7rIHJWkvivIOkwxAxnmik0xs6Mv2U2yMwazRY1vMp8KVG8maHToH1M5hz8tFrZ5 U+fYvNjLlXiA6+Xedhzi5t1xSzYsj0/SqLujYCwBnPHku6SnvvkSz92jn0YqKQM1FmxG Qjlg== X-Gm-Message-State: AOAM533getDxp/l5Kpam+qVyYCK56sgDFnZsX4AEKFfGOYgGBYFAojak boEieRNWO8vRj43IJialihI= X-Google-Smtp-Source: ABdhPJwvgZz8ZoalwA2Ooqk1m9C80RXGOy3Lbb5UQ++hStPSxSVQGys9Ky9d9HHZJyUGDZajWnRipw== X-Received: by 2002:a65:4c87:: with SMTP id m7mr5844727pgt.75.1607054586944; Thu, 03 Dec 2020 20:03:06 -0800 (PST) Received: from js1304-desktop ([114.206.198.176]) by smtp.gmail.com with ESMTPSA id w11sm3205211pfj.212.2020.12.03.20.03.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 20:03:06 -0800 (PST) Date: Fri, 4 Dec 2020 13:02:56 +0900 From: Joonsoo Kim To: Pavel Tatashin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz, mhocko@suse.com, david@redhat.com, osalvador@suse.de, dan.j.williams@intel.com, sashal@kernel.org, tyhicks@linux.microsoft.com, mike.kravetz@oracle.com, rostedt@goodmis.org, mingo@redhat.com, jgg@ziepe.ca, peterz@infradead.org, mgorman@suse.de, willy@infradead.org, rientjes@google.com, jhubbard@nvidia.com Subject: Re: [PATCH 0/6] prohibit pinning pages in ZONE_MOVABLE Message-ID: <20201204035953.GA17056@js1304-desktop> References: <20201202052330.474592-1-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201202052330.474592-1-pasha.tatashin@soleen.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Hello, On Wed, Dec 02, 2020 at 12:23:24AM -0500, Pavel Tatashin wrote: > When page is pinned it cannot be moved and its physical address stays > the same until pages is unpinned. > > This is useful functionality to allows userland to implementation DMA > access. For example, it is used by vfio in vfio_pin_pages(). > > However, this functionality breaks memory hotplug/hotremove assumptions > that pages in ZONE_MOVABLE can always be migrated. > > This patch series fixes this issue by forcing new allocations during > page pinning to omit ZONE_MOVABLE, and also to migrate any existing > pages from ZONE_MOVABLE during pinning. I love what this patchset does, but, at least, it's better to consider the side-effect of this patchset and inform it in somewhere. IIUC, ZONE_MOVABLE exists for two purposes. 1) increasing availability of THP 2) memory hot-unplug Potential issue would come from the case 1). They uses ZONE_MOVABLE for THP availability and hard guarantee for migration isn't required until now. So, there would be a system with following congifuration. - memory layout: ZONE_NORMAL-512MB, ZONE_MOVABLE-512MB - memory usage: unmovable-256MB, movable pinned-256MB, movable unpinned-512MB With this patchset, movable pinned should be placed in ZONE_NORMAL so 512MB is required for ZONE_NORMAL. ZONE_NORMAL would be exhausted and system performance would be highly afftect according to memory usage pattern. I'm not sure whether such configuration exists or not, but, at least, it's better to write down this risk on commit message or something else. Thanks.