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 4EB57C433F5 for ; Wed, 24 Nov 2021 14:41:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A87B96B0075; Wed, 24 Nov 2021 09:41:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A37736B0078; Wed, 24 Nov 2021 09:41:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B1BC6B007B; Wed, 24 Nov 2021 09:41:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0124.hostedemail.com [216.40.44.124]) by kanga.kvack.org (Postfix) with ESMTP id 7D9C66B0075 for ; Wed, 24 Nov 2021 09:41:21 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4D5598248076 for ; Wed, 24 Nov 2021 14:41:11 +0000 (UTC) X-FDA: 78844086342.25.8CB34EA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 972B9508BB83 for ; Wed, 24 Nov 2021 14:41:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637764870; 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=05PN9xn7GnEUgcf2Sc2TC/qS5xmqWs58yCFcmH/P7j0=; b=UTPEwn4h8KxYq86KuF3/TsqWeiXYK6diKDZiBOQsoX2OZpOk4TdjD5mZABRAG5sYMJaxJW kynDvQIz3kU27mKETbzs0SepWGiH3/eJIFiUbYqljJ63M929Y8EmZWrixsaQimsvplLFMr RAzC6xkOgL1vm1ongndWCyeEXculqzo= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-550-LWwZ_2ZvM4eS1aWZ50CR6g-1; Wed, 24 Nov 2021 09:41:08 -0500 X-MC-Unique: LWwZ_2ZvM4eS1aWZ50CR6g-1 Received: by mail-wr1-f69.google.com with SMTP id v18-20020a5d5912000000b001815910d2c0so549199wrd.1 for ; Wed, 24 Nov 2021 06:41:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=05PN9xn7GnEUgcf2Sc2TC/qS5xmqWs58yCFcmH/P7j0=; b=gbp2sE5xJ3knkhuH8s2oUs77A74XAy45kpWJbYgBuPlAsOchDB6um8eUX3/ZxaMB3Z yJgogDHpj4ShoRtR00NofKM+aKbBgdNxod2UQRDyEbE1wXHkc5lx0ac10O+N9eOisQ7y kwZrVYGngDwuYijUyg4MGW0YLVdIRcC8TB9UxK9LXz3jFlHxOwDnBu+FId7L5RGmPiqH ID2OmpLeZ79InkcaUcdKeymgwgPAeFFopd0MSTtd4fuW6oHv8cTR80T4LLk3pi3/mDmr nBOLejbHvdGHBxOv4ERBMr+RBEmBViKKNjM1hWSaq2zQ6IM1zZLHMgpIx3otIEcjckvk m2Eg== X-Gm-Message-State: AOAM532OWidDP5pCiJRi6Nyk/rKS1inWCAZXmR3rYYs6PzIOznARQ2Yb OHMUKJEZsvGdWmpUKccbdt0hygfD6FxY8XSKKTRHoZOOE2rC0yjd/E2i+y8gMXQ773Chz/yJTRr ZVKUt9kCBOjM= X-Received: by 2002:a7b:c008:: with SMTP id c8mr15311373wmb.87.1637764867394; Wed, 24 Nov 2021 06:41:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJxF7ZFf+xn1AKx+sORexMmiOn/XrWXeSdy5eaDUZxe1RqZJyUBzwaHLdz+J+JQnLnMzS44+XA== X-Received: by 2002:a7b:c008:: with SMTP id c8mr15311334wmb.87.1637764867166; Wed, 24 Nov 2021 06:41:07 -0800 (PST) Received: from [192.168.3.132] (p5b0c6380.dip0.t-ipconnect.de. [91.12.99.128]) by smtp.gmail.com with ESMTPSA id l8sm5226970wmc.40.2021.11.24.06.41.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 06:41:06 -0800 (PST) Message-ID: Date: Wed, 24 Nov 2021 15:41:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH] Increase default MLOCK_LIMIT to 8 MiB To: Vlastimil Babka , Jason Gunthorpe Cc: 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 References: <8f219a64-a39f-45f0-a7ad-708a33888a3b@www.fastmail.com> <333cb52b-5b02-648e-af7a-090e23261801@redhat.com> <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> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 972B9508BB83 X-Stat-Signature: k47ppyei47z7t3q1hrcjtbu5u8cdyoj5 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UTPEwn4h; spf=none (imf05.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1637764864-287417 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 24.11.21 15:37, Vlastimil Babka wrote: > On 11/24/21 09:57, David Hildenbrand wrote: >> On 24.11.21 00:59, Jason Gunthorpe wrote: >>>> Similarly for io-uring we could be migrating pages to be pinned so that >>>> the end up consolidated close together, and prevent pathologic >>>> situations like in David's reproducer. >>> >>> It is an interesting idea to have GUP do some kind of THP preserving >>> migration. >> >> >> 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). > > Hm I see, then we could also condsider making it possible to migrate the > pinned pages - of course io-uring would have to be cooperative here, > similarly to anything that supports PageMovable. I might be wrong but that would then essentially be an actual mlock+mmu notifier mechanism, and no longer FOLL_LONGTERM. And the mlock could actually be done by user space and would be optional. I'd be very happy to see something like that instead ... but so far people don't even agree that it's an issue worth fixing. So ... -- Thanks, David / dhildenb