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 51C22C32771 for ; Wed, 28 Sep 2022 08:49:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB9058E0134; Wed, 28 Sep 2022 04:49:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C68658E0120; Wed, 28 Sep 2022 04:49:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B57368E0134; Wed, 28 Sep 2022 04:49:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id A4B918E0120 for ; Wed, 28 Sep 2022 04:49:32 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 76FBD4110D for ; Wed, 28 Sep 2022 08:49:32 +0000 (UTC) X-FDA: 79960870584.08.2D7F62D Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf11.hostedemail.com (Postfix) with ESMTP id 1DE6B40011 for ; Wed, 28 Sep 2022 08:49:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664354971; x=1695890971; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=qKQIq21NKAdBYO/NiB/2nQyRgzRAJfVSm/FkW9deYnM=; b=ajeqsGwGgRjvyqeMcUZEaSKMs6eYqvd1f1GLh4z9/W1WKJ06b4NATTdm zsIq4HBY6ztVcwJkMQQux2El2LSmyNp5/Rx3deXNeRrHIV4NIC+s1k+Eo Jx90ptL9Re7cuMcyFM57XFINO6CIWAKsLuRBWrPoa7GT48N2zHbgAg+aX FEAC+re8TPtFquHeFpdY4Un40Vz/5y5qZ/eW5nb3/8JT3kLTB/q+nTH8s P2PESue/O5gCtzNNG1FTR+QKxPkoMEEjvZlDKE159A9tOrUP0+ZUSuNZZ Sfj1iqn/NscE2Q+MOsLavzm950TR1DUc7iBQ2htcoWlZJCErylDIgZc3F A==; X-IronPort-AV: E=McAfee;i="6500,9779,10483"; a="302457561" X-IronPort-AV: E=Sophos;i="5.93,351,1654585200"; d="scan'208";a="302457561" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2022 01:49:29 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10483"; a="655051213" X-IronPort-AV: E=Sophos;i="5.93,351,1654585200"; d="scan'208";a="655051213" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2022 01:49:27 -0700 From: "Huang, Ying" To: Cc: , , , , , , Subject: Re: [PATCH 2/3] mm: changes to split_huge_page() to free zero filled tail pages References: <94de34378bb748196e7709205a75331569d1d28e.1664347167.git.alexlzhu@fb.com> Date: Wed, 28 Sep 2022 16:48:40 +0800 In-Reply-To: <94de34378bb748196e7709205a75331569d1d28e.1664347167.git.alexlzhu@fb.com> (alexlzhu@fb.com's message of "Tue, 27 Sep 2022 23:44:12 -0700") Message-ID: <87v8p728bb.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664354972; a=rsa-sha256; cv=none; b=WGN/qZ0pi3LyaqKjrah0GFKoh/SZzc/pwH0RSRVJYs7kyD83ZqSDTW7T6KWIp88N22TLfy A33WqTk/MBT/6UVnNoWoLpFecSeZ6Zr3wUteyG5NV0Zjo0i/AjbCyIoWayTwOmjC5sbjri f9FGj8+Yp8E798Z5003FVEoeCOLMOo0= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=ajeqsGwG; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf11.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664354972; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ij95DMLuSL6rnC2KbOmSgdQIiOakyz9XRIbNnhKUbgE=; b=hoYqoebxf7ymxYcUhjogab7q1d93MqV60JoBG4CH5ffeE9eaqPELszNUdvQav6TqTIviNf eAi7KQMDs1YZB3qv3aSIi7hX5Nz2/32OKw7tiiT5KgNvnewP9o5OqaXNcDjPMuhDw81URl ls5HWK+w++wNUCgj14e0dBssPNAHoCc= X-Rspam-User: X-Rspamd-Queue-Id: 1DE6B40011 Authentication-Results: imf11.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=ajeqsGwG; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf11.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.24 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-Stat-Signature: 4erkprsy63uabkhra15zhwq98fz4ssq7 X-Rspamd-Server: rspam07 X-HE-Tag: 1664354970-2556 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: writes: > From: Alexander Zhu > > Currently, when /sys/kernel/mm/transparent_hugepage/enabled=always is set > there are a large number of transparent hugepages that are almost entirely > zero filled. This is mentioned in a number of previous patchsets > including: > https://lore.kernel.org/all/20210731063938.1391602-1-yuzhao@google.com/ > https://lore.kernel.org/all/ > 1635422215-99394-1-git-send-email-ningzhang@linux.alibaba.com/ > > Currently, split_huge_page() does not have a way to identify zero filled > pages within the THP. Thus these zero pages get remapped and continue to > create memory waste. In this patch, we identify and free tail pages that > are zero filled in split_huge_page(). In this way, we avoid mapping these > pages back into page table entries and can free up unused memory within > THPs. This is based off the previously mentioned patchset by Yu Zhao. > However, we chose to free anonymous zero tail pages whenever they are > encountered instead of only on reclaim or migration. > > We also add self tests to verify the RssAnon value to make sure zero > pages are not remapped except in the case of userfaultfd. In the case > of userfaultfd we remap to the shared zero page, similar to what is > done by KSM. > > Signed-off-by: Alexander Zhu > --- > include/linux/rmap.h | 2 +- > include/linux/vm_event_item.h | 3 + > mm/huge_memory.c | 44 ++++++- > mm/migrate.c | 72 +++++++++-- > mm/migrate_device.c | 4 +- > mm/vmstat.c | 3 + > .../selftests/vm/split_huge_page_test.c | 113 +++++++++++++++++- > tools/testing/selftests/vm/vm_util.c | 23 ++++ > tools/testing/selftests/vm/vm_util.h | 1 + > 9 files changed, 250 insertions(+), 15 deletions(-) > > diff --git a/include/linux/rmap.h b/include/linux/rmap.h > index b89b4b86951f..f7d5d5639dea 100644 > --- a/include/linux/rmap.h > +++ b/include/linux/rmap.h > @@ -372,7 +372,7 @@ int folio_mkclean(struct folio *); > int pfn_mkclean_range(unsigned long pfn, unsigned long nr_pages, pgoff_t pgoff, > struct vm_area_struct *vma); > > -void remove_migration_ptes(struct folio *src, struct folio *dst, bool locked); > +void remove_migration_ptes(struct folio *src, struct folio *dst, bool locked, bool unmap_clean); There are 2 bool parameters now. How about use "flags" style parameters? IMHO, well defined constants are more readable than a set of true/false. Best Regards, Huang, Ying [snip]