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 CFD89C433EF for ; Thu, 25 Nov 2021 10:09:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CAE86B0074; Thu, 25 Nov 2021 05:09:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4546B6B0075; Thu, 25 Nov 2021 05:09:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2CE676B007B; Thu, 25 Nov 2021 05:09:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 16C046B0074 for ; Thu, 25 Nov 2021 05:09:41 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D261380D4603 for ; Thu, 25 Nov 2021 10:09:30 +0000 (UTC) X-FDA: 78847030458.17.B9D3103 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 8F1579000508 for ; Thu, 25 Nov 2021 10:09:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637834969; 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=/JJz0qEyNzReubdlE4bgJTpQjKIHhlioIGoaUH7sJe0=; b=aVQWDbzKAv8jt3jaSkLdYhreFu/Bjh0Hx7Bq+fmV7CAREh08ZdRNzcV+kijiLRC6zLu5/M 2KoFxXNEsfOuQv3kpmMiq8wSlJBIz9/IAw1EzVFY6c83yK9sx75XMedTwfj5WLL2yJMTv1 CKcIaeLVcWPPhAR4LEHJo4VwCoIBO+w= Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-309-SChNkyFvP5adF2kH-NOG7g-1; Thu, 25 Nov 2021 05:09:27 -0500 X-MC-Unique: SChNkyFvP5adF2kH-NOG7g-1 Received: by mail-pl1-f200.google.com with SMTP id m17-20020a170902db1100b001421cb34857so1881280plx.15 for ; Thu, 25 Nov 2021 02:09:27 -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=/JJz0qEyNzReubdlE4bgJTpQjKIHhlioIGoaUH7sJe0=; b=vwuQdr2Xau7ATZ0LYUU1e6OqJL1yFBVAuYwvjxi4rEo258vJcdhAFpADQnYkavS5Y+ RLYsxlXzcKZ1bzR0CKcBMAmzieVItW8SVYw/mmbb8t7ORt5NjbUgixCbAzQ8dUKMXEaQ W6VkzMzT7afRynNFtueD9+wPfNEjoRMAiWZ4N6+o4rikOIxX9CyrURuNeq5ymUSedkvM ccr7pjvfasmYsYRoXus9MX110lHnRXoSsNBn14pdjFEqFNuat6PwpnSK4ux8Hj4Xkxzs IaRfZkoUfWXpV/rCxN3sEyAovl3AKWz2X8vUVLDl0t2pmPeoJe0vHpP6NPks+p9VoJfK j+1g== X-Gm-Message-State: AOAM532M64+N2O9aT9WHuG66h+jv4V6FQv+rlzUq3ZCFpfJmiwNTQZNr THm9wuFR/CXMZawK7e+O10TTa2nezMBXxaGvlp8kcx66TLsiN/vZEOfIIkazEPluqhdBlbs2rFH kQzHLBN7J6/A= X-Received: by 2002:a17:90b:4c02:: with SMTP id na2mr5628671pjb.94.1637834966708; Thu, 25 Nov 2021 02:09:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJze6OQsdVwHY+zRy+pZmJn5TkhSeCuJ4mD0b9601Z+uulZVYsL5U3/Z5lkS3fu+G93IwYTp7A== X-Received: by 2002:a17:90b:4c02:: with SMTP id na2mr5628628pjb.94.1637834966388; Thu, 25 Nov 2021 02:09:26 -0800 (PST) Received: from xz-m1.local ([94.177.118.150]) by smtp.gmail.com with ESMTPSA id p8sm3002445pfo.141.2021.11.25.02.09.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Nov 2021 02:09:25 -0800 (PST) Date: Thu, 25 Nov 2021 18:09:19 +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: <25b36a5c-5bbd-5423-0c67-05cd6c1432a7@redhat.com> <1b30d06d-f9c0-1737-13e6-2d1a7d7b8507@redhat.com> <92fe0c31-b083-28c4-d306-da8a3cd891a3@redhat.com> <1b400921-8bef-8073-10f9-a7cbb09cfefe@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: rspam01 X-Rspamd-Queue-Id: 8F1579000508 X-Stat-Signature: 6z5u4d9iskkt7u44bobn7srtwm4u79bn Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=aVQWDbzK; spf=none (imf28.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1637834969-673963 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 Tue, Nov 23, 2021 at 09:28:34AM -0800, Shakeel Butt wrote: > On Tue, Nov 23, 2021 at 9:26 AM David Hildenbrand wrote: > > > > On 23.11.21 18:24, Shakeel Butt wrote: > > > On Tue, Nov 23, 2021 at 9:20 AM David Hildenbrand wrote: > > >> > > >> On 23.11.21 18:17, Shakeel Butt wrote: > > >>> On Tue, Nov 23, 2021 at 8:57 AM David Hildenbrand wrote: > > >>>> > > >>> [...] > > >>>>>> > > >>>>>> I do wonder which these locking contexts are exactly, and if we could > > >>>>>> also do the same thing on ordinary munmap -- because I assume it can be > > >>>>>> similarly problematic for some applications. > > >>>>> > > >>>>> This is a good question regarding munmap. One main difference is > > >>>>> munmap takes mmap_lock in write mode and usually performance critical > > >>>>> applications avoid such operations. > > >>>> > > >>>> Maybe we can extend it too most page zapping, if that makes things simpler. > > >>>> > > >>> > > >>> Do you mean doing sync THP split for most of page zapping functions > > >>> (but only if that makes things simpler)? > > >>> > > >> > > >> Yes -- if there are no downsides. > > >> > > > > > > I will try. At the moment the assumption of "Not null zap_details > > > implies leave swap entries" is giving me a headache. > > > > Not only you, did you stumble over > > > > https://lkml.kernel.org/r/20211115134951.85286-1-peterx@redhat.com (thanks for raising this, David) > > > > already? > > > > Oh thanks for the pointer. I missed that. I will take a look. Thanks again. Hi, Shakeel, I saw your v2 has started to pass in zap_details, then we need know the side effect on that skip-swap-entry thing because with your v2 code munmap() will start to skip swap entry too (while it was not before). I saw that you didn't mention this in v2 patch either in commit message or code, not sure whether you digged that up. I think it needs some double check (or feel free to start this digging by reviewing my small patch above :). Thanks, -- Peter Xu