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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19D8AC433EF for ; Wed, 24 Nov 2021 13:24:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D2DF6B0078; Wed, 24 Nov 2021 08:24:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 782FA6B007B; Wed, 24 Nov 2021 08:24:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 649F66B007D; Wed, 24 Nov 2021 08:24:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0055.hostedemail.com [216.40.44.55]) by kanga.kvack.org (Postfix) with ESMTP id 5613A6B0078 for ; Wed, 24 Nov 2021 08:24:06 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1ADBB886C8 for ; Wed, 24 Nov 2021 13:23:56 +0000 (UTC) X-FDA: 78843891630.20.8A9ED10 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf09.hostedemail.com (Postfix) with ESMTP id 2F78B3000886 for ; Wed, 24 Nov 2021 13:23:52 +0000 (UTC) Received: by mail-qv1-f47.google.com with SMTP id i13so1744587qvm.1 for ; Wed, 24 Nov 2021 05:23:55 -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=vR5X7aTiFOOVGN8Rdr9twInRzNQE68Jn7eaS79KF5JI=; b=Ql2jamGTDoo7tRUYmapHPNuQGI2EBH53GGT10ws9BRT9mp46w8Q3WwC3bQcPjeyJUb bDlBo8Chiuh50ahwDix4xn/QkQqNYaECP7iHe7aFuqQ+GnbXtLePsHEQYi8iJLbO8jqG NeYdwLTquLM5mylQwGgCeaeQkp0LBt1Yn1Rqo+zq6gwOGYUG9Po4+HaTCnO+dQNQOo9u /H7S4tZq/gdk39EiB3cmL6+u0dGvJcgyz0lJGS50HCetT00czUmh7PpLQWvPGx6Qxi6k OC/IM/Z8a6CY0jkeVQY6DjARa3DtW+KgCl9Ll6TBgitPiQ0pysSPg1B/wYFjftVk3MfZ N+lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=vR5X7aTiFOOVGN8Rdr9twInRzNQE68Jn7eaS79KF5JI=; b=H2jYV0mXhULwrwLR8hdFs49+YZVHnVRzawp84P0Ox5BEmPWMBZ/beUYwi7GZfhQ9F4 qJ+mOaxxwSXe++YTudAzlrsLgllqLjz5/VY3C5kko2Ntmz2pnNFuQgM4AwWCYhbGdnJs AkVOei8Nx7gTNZZY4gQJii2am6z2Orf95Hc3IqTNl53BTf2T8RnUNLN4QsWbdIHBHZ99 waN+Vd3GzC6EBBhjQkxYiLRqJHOv+ryNG16OlJ7FUFU0pxJMxZ5H7x0eRfnDzokGC4Md vbhoqUvYCInq4M4gvu3lOtvFh0WDOUoIOAXhsEK3iH+VnObOo4gepctgpF9mWCXirBAo Rrzw== X-Gm-Message-State: AOAM531wUhqG9msguAp+eYINp+EvN7WnvpUa5+5pQGHkMOTaoOdWMkYm 0HVLCVJojUBsibpVdONK8PHIhg== X-Google-Smtp-Source: ABdhPJwIkO/hSHdrvxMNPMQTiV33oMboBFQ2VKpVaquqdmUVNR+JyQZWlHq5jUxy9L7WR3iB7jccJg== X-Received: by 2002:ad4:576a:: with SMTP id r10mr7232232qvx.5.1637760234949; Wed, 24 Nov 2021 05:23:54 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id u7sm8522541qkp.17.2021.11.24.05.23.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Nov 2021 05:23:54 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mpsFd-0011Ar-RE; Wed, 24 Nov 2021 09:23:53 -0400 Date: Wed, 24 Nov 2021 09:23:53 -0400 From: Jason Gunthorpe To: David Hildenbrand Cc: Vlastimil Babka , Jens Axboe , Andrew Dona-Couch , Andrew Morton , Drew DeVault , Ammar Faizi , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, io_uring Mailing List , Pavel Begunkov , linux-mm@kvack.org Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB Message-ID: <20211124132353.GG5112@ziepe.ca> References: <5f998bb7-7b5d-9253-2337-b1d9ea59c796@redhat.com> <20211123132523.GA5112@ziepe.ca> <10ccf01b-f13a-d626-beba-cbee70770cf1@redhat.com> <20211123140709.GB5112@ziepe.ca> <20211123170056.GC5112@ziepe.ca> <20211123235953.GF5112@ziepe.ca> <2adca04f-92e1-5f99-6094-5fac66a22a77@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2adca04f-92e1-5f99-6094-5fac66a22a77@redhat.com> X-Stat-Signature: g8gta8cxp4dodx1793s8tr1hsdbcdtis X-Rspamd-Queue-Id: 2F78B3000886 X-Rspamd-Server: rspam07 Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=Ql2jamGT; spf=pass (imf09.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.47 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none X-HE-Tag: 1637760232-51312 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 Wed, Nov 24, 2021 at 09:57:32AM +0100, David Hildenbrand wrote: > Unfortunately it will only be a band aid AFAIU. I can rewrite my > reproducer fairly easily to pin the whole 2M range first, pin a second > time only a single page, and then unpin the 2M range, resulting in the > very same way to block THP. (I can block some THP less because I always > need the possibility to memlock 2M first, though). Oh! The issue is GUP always pins an entire compound, no matter how little the user requests. However, when all the GUP callers do mlock accounting they have no idea how much memory GUP actually pinned and only account mlock on 4K chunks. This is the bug your test is showing - using this accounting error the user can significantly blow past their mlock limit by having GUP pin 2M chunks and then mlock accounting for only 4k chunks. It is a super obnoxious bug to fix, but still just a bug and not some inherent defect in FOLL_LONGTERM. It also says the MLOCK_LIMIT really needs to always be > 1 THP otherwise even a single 4K page may be unpinnable with correct accounting. Jason