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 3F927C433F5 for ; Thu, 25 Nov 2021 10:24:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B22ED6B0074; Thu, 25 Nov 2021 05:24:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD32A6B0075; Thu, 25 Nov 2021 05:24:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C1DF6B007B; Thu, 25 Nov 2021 05:24:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 8CEE86B0074 for ; Thu, 25 Nov 2021 05:24:37 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 552B18E56B for ; Thu, 25 Nov 2021 10:24:27 +0000 (UTC) X-FDA: 78847067838.19.BD55243 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id E233220019EB for ; Thu, 25 Nov 2021 10:24:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637835866; 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: in-reply-to:in-reply-to:references:references; bh=YAs+wOcrTysA9YV1Vf8sngcPa3FxWosi6YTl8VNcjbQ=; b=K1jCYigWjsquTvNwztZuDl01wpO7G7d6mOTU9JCRum+vTbij2SEzmHxUIy420fcQMeUPkA HbzUsgtfGfhpOM1Pyh4GwEVy+c8PQfsky9agISF0y6+oPdTB1eYrVJ1iuFabtnogDY6IH6 VhjbYoggl/UBWVVPzwALKaI+/iu3WV0= Received: from mail-pg1-f198.google.com (mail-pg1-f198.google.com [209.85.215.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-520-wZYBnL52N6S_Lc_A4hNNZg-1; Thu, 25 Nov 2021 05:24:25 -0500 X-MC-Unique: wZYBnL52N6S_Lc_A4hNNZg-1 Received: by mail-pg1-f198.google.com with SMTP id 31-20020a630a1f000000b00324b8186ef0so1540391pgk.23 for ; Thu, 25 Nov 2021 02:24:24 -0800 (PST) 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=YAs+wOcrTysA9YV1Vf8sngcPa3FxWosi6YTl8VNcjbQ=; b=Vt/jOSwFYwpzp8dBC5OQhoqKYN1+5cn5mUUneQuwUKdt2dekHgGSerqUS9H2spz49T CcWhQfHARFZ5uMgBWsfiFEZQy13a8V/AK3qUhvCF7zvo9fz5cftVlSrlkf1+Wc0bskk3 9li+HcWebVUMDoqGqmOMcVlN3uHk/fujJLa0/FWA8Y1HH12BO+KzWvwvwUBB+rewp/G4 z6zBSE4gypc4lSssA2ZicJB+LUqT120Sw+SGl1u6WHIE+LMIEc4xFlaFoJSonOdRgd+N fn6ZEvu2bHQBRHBweSG+nOC0qZzB/YjAPIRwYWB/Axfp3OcmVzJN4V3YSLOquzefvbOr Af9g== X-Gm-Message-State: AOAM532H4b9vQXmoWWkZKmjko/rjKnXs5BpeVt8zfpuCvljG0fvGBftW qPTypdMaEfLvK4IjsDYFyjOMSiAsCY7Reoeaxo+VS1QY3xj5OVWTE+NzWrompz96nwVcp0GXNKO HOwmfDzMtrHI= X-Received: by 2002:a63:894a:: with SMTP id v71mr15286634pgd.337.1637835863645; Thu, 25 Nov 2021 02:24:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJwhTSMgJfEb1p1gaKmYXk/HSshjHdQmPcVfAvtIixKoiBODtcQEZlOalgLPB6QdfLRbmM/NZg== X-Received: by 2002:a63:894a:: with SMTP id v71mr15286579pgd.337.1637835862911; Thu, 25 Nov 2021 02:24:22 -0800 (PST) Received: from xz-m1.local ([94.177.118.150]) by smtp.gmail.com with ESMTPSA id il7sm2606487pjb.54.2021.11.25.02.24.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Nov 2021 02:24:22 -0800 (PST) Date: Thu, 25 Nov 2021 18:24:16 +0800 From: Peter Xu To: Shakeel Butt Cc: David Hildenbrand , "Kirill A . Shutemov" , Yang Shi , Zi Yan , Matthew Wilcox , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: split thp synchronously on MADV_DONTNEED Message-ID: References: <20211120201230.920082-1-shakeelb@google.com> <25b36a5c-5bbd-5423-0c67-05cd6c1432a7@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E233220019EB X-Stat-Signature: 334k4bp5d3dsgyqjhby3diaebiz5zwop Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=K1jCYigW; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf26.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-HE-Tag: 1637835865-254456 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 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. To me, the old deffered-split has a point in that it'll only be done when at least the memory or cgroup is in low mem, that means we're in extreme cases so we'd better start to worry page allocation failures rather than number of thps and memory performance. v2 even added unmap() into account, so that'll further amplify that effect, imho. I'm wondering whether MADV_SPLIT would make more sense so as to keep the old DONTNEED/unmap behaviors, however before that I think I should understand the test results first, because besides 2m pages missing that'll be another important factor for "whether a new interface is more welcomed" from perf pov. Thanks, -- Peter Xu