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 5DB4CC433EF for ; Thu, 25 Nov 2021 10:32:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4ECE6B0074; Thu, 25 Nov 2021 05:32:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFEC06B0075; Thu, 25 Nov 2021 05:32:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CEE0A6B007B; Thu, 25 Nov 2021 05:32:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0184.hostedemail.com [216.40.44.184]) by kanga.kvack.org (Postfix) with ESMTP id C0C9B6B0074 for ; Thu, 25 Nov 2021 05:32:23 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8202618508669 for ; Thu, 25 Nov 2021 10:32:13 +0000 (UTC) X-FDA: 78847087788.21.649494C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf23.hostedemail.com (Postfix) with ESMTP id E6B8B90000A0 for ; Thu, 25 Nov 2021 10:32:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637836332; 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=R2830KMnShyNuf2bxSXiCKSiHB3AQr1k1blCmoANtdQ=; b=PbTVDFnKaghO2eP0CtGdYQ7l77YQOnn+CF/s/D7M1aI7Nxcxa3L6N36iRFQp1FNwdFM/SJ E6uXlsQWNNvZvJdfsM5zcVRiWCgV9FtM0Lw4TOP7BX5Pqx9K8Pl5GIKZyrUCTLBJBpxZa4 V+lUPqZGJfs2VXyge3/Kq+xXb0yksyk= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-133-C007rH5vNpOgGZLUGq6eSg-1; Thu, 25 Nov 2021 05:32:11 -0500 X-MC-Unique: C007rH5vNpOgGZLUGq6eSg-1 Received: by mail-wm1-f72.google.com with SMTP id n16-20020a05600c3b9000b003331973fdbbso3281393wms.0 for ; Thu, 25 Nov 2021 02:32:11 -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 :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=R2830KMnShyNuf2bxSXiCKSiHB3AQr1k1blCmoANtdQ=; b=z5OQ/qVietfl2lR/L8UdZvGIlikUMF8VBbwzPAnrQs1qxB8qdztPqKs2Nv/XcoKu3f X86IUTwUHS1u0cavHWcUPmpwaArsa5x/3rOs9tdAuGe/f8mbtmXN5FesRF36a7lbZ2Of LukkbC0khY8wjnP9ij0xNpLp1sqsKOUuNozE4r9nWOAJU6vDqvkCr0MFIqbXRjd820Xd AIcMAkwzhGRwY+dnLzkku8G1JNuwyeOW2hqQryuBxuCExQH9Bd8e5m/sNOzVbH5zKzRw 5VH7sVCVFqKcboPC5GG3VokeU14iUS3hZSBuVnfLMNvcMQbD/vqISz86ixy9hgeyBc96 khlQ== X-Gm-Message-State: AOAM5301KneTAgbrBY6ezswGMEZitXpkp84GVxFCmlq3YOlYBGF8ejcg 345gPWQot+6pZNzeijjkQrI4J2RbGemjzDd7ipWakcnV6mXGOEQ0fGEaMpqHvhL3CLqHc8hSaUg NsHeAvpIan9U= X-Received: by 2002:a05:600c:22cb:: with SMTP id 11mr5732450wmg.181.1637836330049; Thu, 25 Nov 2021 02:32:10 -0800 (PST) X-Google-Smtp-Source: ABdhPJz7t63uIqqTxzhaKcTf1lT56VtFnAZirrfQW8WEA3StqKFm5yksQdgS/b+gYiHyev/uaIx4vw== X-Received: by 2002:a05:600c:22cb:: with SMTP id 11mr5732419wmg.181.1637836329864; Thu, 25 Nov 2021 02:32:09 -0800 (PST) Received: from [192.168.3.132] (p5b0c679e.dip0.t-ipconnect.de. [91.12.103.158]) by smtp.gmail.com with ESMTPSA id n13sm2528641wrt.44.2021.11.25.02.32.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Nov 2021 02:32:09 -0800 (PST) Message-ID: <57d649c8-fe13-17cd-8819-2cd93500a79c@redhat.com> Date: Thu, 25 Nov 2021 11:32:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: Peter Xu , Shakeel Butt Cc: "Kirill A . Shutemov" , Yang Shi , Zi Yan , Matthew Wilcox , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20211120201230.920082-1-shakeelb@google.com> <25b36a5c-5bbd-5423-0c67-05cd6c1432a7@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm: split thp synchronously on MADV_DONTNEED 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: rspam06 X-Rspamd-Queue-Id: E6B8B90000A0 X-Stat-Signature: toj3uggkmfreh1te53hha8w7ba3grrp3 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PbTVDFnK; spf=none (imf23.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1637836327-800833 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 25.11.21 11:24, Peter Xu wrote: > On Mon, Nov 22, 2021 at 10:40:54AM -0800, Shakeel Butt wrote: >>> Do we have a performance evaluation how much overhead is added e.g., for >>> a single 4k MADV_DONTNEED call on a THP or on a MADV_DONTNEED call that >>> covers the whole THP? >> >> I did a simple benchmark of madvise(MADV_DONTNEED) on 10000 THPs on >> x86 for both settings you suggested. I don't see any statistically >> significant difference with and without the patch. Let me know if you >> want me to try something else. > > I'm a bit surprised that sync split thp didn't bring any extra overhead. > > "unmap whole thp" is understandable from that pov, because afaict that won't > even trigger any thp split anyway even delayed, if this is the simplest case > that only this process mapped this thp, and it mapped once. > > For "unmap 4k upon thp" IIUC that's the worst case and zapping 4k should be > fast; while what I don't understand since thp split requires all hand-made work > for copying thp flags into small pages and so on, so I thought there should at > least be some overhead measured. Shakeel, could there be something overlooked > in the test, or maybe it's me that overlooked? > > I had the same concern as what Kirill/Matthew raised in the other thread - I'm > worried proactively splitting simply because any 4k page is zapped might > quickly free up 2m thps in the system and I'm not sure whether it'll exaggerate > the defragmentation of the system memory in general. I'm also not sure whether > that's ideal for some very common workload that frequently uses DONTNEED to > proactively drop some pages. The pageblock corresponding to the THP is movable. So (unless we start spilling unmovable allocations into movable pageblocks) we'd only place movable allocations in there. Compaction will be able to migrate to re-create a free THP. In contrast I think, compaction will happily skip over the THP and ignore it, because it has no clue that the THP could be repurposed by split+migrate (at least I am not aware of code that does it). Unless I am missing something, with the above in mind it could make sense to split as soon as possible, even before we're under memory pressure -- for example, for proactive compaction. [proactive compaction could try splitting first as well I think] -- Thanks, David / dhildenb