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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 1DF6EC4361A for ; Fri, 4 Dec 2020 16:10:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AA23E2223E for ; Fri, 4 Dec 2020 16:10:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA23E2223E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 28C006B0074; Fri, 4 Dec 2020 11:10:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2624E6B0075; Fri, 4 Dec 2020 11:10:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 179476B0078; Fri, 4 Dec 2020 11:10:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id EFE206B0074 for ; Fri, 4 Dec 2020 11:10:20 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 76D36363E for ; Fri, 4 Dec 2020 16:10:20 +0000 (UTC) X-FDA: 77556087000.26.taste89_1011b11273c5 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 114B41804B660 for ; Fri, 4 Dec 2020 16:10:20 +0000 (UTC) X-HE-Tag: taste89_1011b11273c5 X-Filterd-Recvd-Size: 6231 Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com [209.85.160.195]) by imf13.hostedemail.com (Postfix) with ESMTP for ; Fri, 4 Dec 2020 16:10:07 +0000 (UTC) Received: by mail-qt1-f195.google.com with SMTP id z3so4245255qtw.9 for ; Fri, 04 Dec 2020 08:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=VgRFU7+U3dcM21Ber7g78naiXHMx8/x0mx6S23m379c=; b=TxQQ3A4gPUb/c6DaNSH8sSZrpSZ6sh+4Kao8BUigB8ZB0+dG67Z7ykp2uwIWWShMWk UKN+qrOzqwIa1PPeKfy+NpjPfj04Ckq6aAHGudbjMJHEotnoqGM+emLLcQh1+ECQ7lbg 1I4RWNBxawpsn4sERFYuKUnYJmx+QJnUXAQgtXZ+GYcfI7xeMKvpo1tnhquqzHMp6G95 TpTsY3FOT91lCb0ofY3U/iMb+WVfV2Av8BcKN05VanSsIInlyn/ntD7UlBwoA4RzoeGX +zRTNsADj7a0zPLZ5xa+CWuiPQlu28cMhvJb9o1ykX60oLPDmsHXlwEXGAVBEqqILXEn +bqA== 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=VgRFU7+U3dcM21Ber7g78naiXHMx8/x0mx6S23m379c=; b=NvfBw35WtRan5haIY4o0hKp/SJvIrkxlPeejWLK/17BWlhAHIgYIY02Mq3hH2oMYoT s4MNu39WiJi+Ja7D+f18wL68sc56fzERVAxAj7caGKUDliLW1VU8m+fBri1R5QNd2/N+ i0FwiRA5IITOpSzS3GM5/LzEM3WLOgD6t5plU5QBSNlbhm7k9cQ2X0wiRZhkLex/LWNU KFzIpmk5JhO6OL83u1Z5QBLIdgHbqpE23L4APmoa40aUMF0SgwGVlZAGxFR/8Dna+Oql CiwUOPlTwtD8hJzcnyFildHgO502Um+lsEKtXkSYAmF1KFtmi4d+QaKg7FuG4D8kUYFg AnrA== X-Gm-Message-State: AOAM5311LzyyhEO6zKvA3zttNjSrgOrEVNuAcW47vEmkaDQAurws5cYR DaxC3hVj/fMGrUT84+IJVqzE0A== X-Google-Smtp-Source: ABdhPJyJBAEvJJb4cjudhvvR8M4t3aSdim44E4b1pefhuATcOoSqitkM9LGsEmvZ/5HNVRh6F6PjXA== X-Received: by 2002:ac8:4f11:: with SMTP id b17mr10092063qte.338.1607098206515; Fri, 04 Dec 2020 08:10:06 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-156-34-48-30.dhcp-dynamic.fibreop.ns.bellaliant.net. [156.34.48.30]) by smtp.gmail.com with ESMTPSA id z20sm5167491qto.40.2020.12.04.08.10.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Dec 2020 08:10:05 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1klDen-005vbe-3D; Fri, 04 Dec 2020 12:10:05 -0400 Date: Fri, 4 Dec 2020 12:10:05 -0400 From: Jason Gunthorpe To: Pavel Tatashin Cc: Joonsoo Kim , LKML , linux-mm , Andrew Morton , Vlastimil Babka , Michal Hocko , David Hildenbrand , Oscar Salvador , Dan Williams , Sasha Levin , Tyler Hicks , mike.kravetz@oracle.com, Steven Rostedt , Ingo Molnar , Peter Zijlstra , Mel Gorman , Matthew Wilcox , David Rientjes , John Hubbard Subject: Re: [PATCH 0/6] prohibit pinning pages in ZONE_MOVABLE Message-ID: <20201204161005.GD5487@ziepe.ca> References: <20201202052330.474592-1-pasha.tatashin@soleen.com> <20201204035953.GA17056@js1304-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Fri, Dec 04, 2020 at 10:55:30AM -0500, Pavel Tatashin wrote: > On Thu, Dec 3, 2020 at 11:03 PM Joonsoo Kim wrote: > > > > 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. > > Yes, this indeed could be a problem for some configurations. I will > add your comment to the commit log of one of the patches. It sounds like there is some inherent tension here, breaking THP's when doing pin_user_pages() is a really nasty thing to do. DMA benefits greatly from THP. I know nothing about ZONE_MOVABLE, is this auto-setup or an admin option? If the result of this patch is standard systems can no longer pin > 80% of their memory I have some regression concerns.. Jason