Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: Mapcount of subpages
To:     Matthew Wilcox <willy@infradead.org>,
        Kent Overstreet <kent.overstreet@gmail.com>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, Johannes Weiner <hannes@cmpxchg.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Darrick J. Wong" <djwong@kernel.org>,
        Christoph Hellwig <hch@infradead.org>,
        David Howells <dhowells@redhat.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>
References: <YUvWm6G16+ib+Wnb@moria.home.lan>
 <YUvzINep9m7G0ust@casper.infradead.org> <YUwNZFPGDj4Pkspx@moria.home.lan>
 <YUxnnq7uFBAtJ3rT@casper.infradead.org>
From:   Mike Kravetz <mike.kravetz@oracle.com>
Message-ID: <470145d5-8bc4-19cc-66ea-8e8610b7529a@oracle.com>
Date:   Thu, 23 Sep 2021 11:56:26 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.1.1
In-Reply-To: <YUxnnq7uFBAtJ3rT@casper.infradead.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?c2NsUTRBLzNtS0hadzFWU2M2WDhPMXZTaEdlYUc0N1BJcUFldXhzaU9YRVln?=
 =?utf-8?B?cld0YlpCOWducVU3REk0SXhUWVg4VVBnb1U0TGcwQnQyNk1KbjNnUUhhSkll?=
 =?utf-8?B?ZGhiYVI1ZENIS2pIZXdnOWFwUXpkM1J3SC95V3N6YUVvT3JBdUJONzRCLzc1?=
 =?utf-8?B?TVJJNU9hU2tZdEJYa3RnSFBva1FIek55VUV3cDNQK3hOWGdXdVVlT0pMMFhR?=
 =?utf-8?B?NDU4Z3hCQ1lTS1VxT0Q1d1BrNkJzTGlYZTU2R2RSWm45NmgxVlRRZWhQQ0gy?=
 =?utf-8?B?anBqSER4VDR5bWVEdk5vYUZOekhQVEhncWYybTF0Q0ViNWo1LzVGZGVqNTN6?=
 =?utf-8?B?MFpPS21oaWxtaWF6WnJYSk1qV3pKdlIzanZBdUZKU200UG5iVllOL3JnQlJK?=
 =?utf-8?B?TWdJa0ROb0tUREd3QXNHSU41c3hBaGI4dDVTMmducjdRVlRVam5OemxOd3VJ?=
 =?utf-8?B?Nm9PQkFTWlZWQVZqb2xvdEQyZHZNSHliRHJsVzJOOFNBdUNpN3EwMkNGSFBX?=
 =?utf-8?B?bW9qcjFqbzFqbFVZSUIxT2h0VE9QbmhLYW9BM1YzMXQ1dVp6WDZpVEsrK08y?=
 =?utf-8?B?STNCTGkvUXZoU0wrbUVpb3RQTjJRMS9QME81Q3JubzBSNm4zZ0hSUHdoejhu?=
 =?utf-8?B?RmNHenBJeGNTUDlHbkhta1lSeVBjYWNFamtxdjJqREdQcExBdE04NmZ3Q04y?=
 =?utf-8?B?SW1ZY0ErSkYraERhUkczTmx2cjF5QUFBVlRBN294SWJoWFVRRkdTaUtWYm9R?=
 =?utf-8?B?QW9Na3NvQmp6RW1mZ1gyRWVDS2tDd2FwS1lsb1JySkNReHFTWEliNmZJKzJG?=
 =?utf-8?B?WGpIOG5ZeHJoWG5SK2htWUJPeFp6bzNqYmhYSDRINjZQZ2VjMkRLTmJXS0hz?=
 =?utf-8?B?aXY2cXV6YnRWOTJhSXhrM2JhZnBRUVVWQkVuOFJxRUtKVWJOcUdRK2FGYzFz?=
 =?utf-8?B?bk1iQlJJc1BnaWhNNHkyQlh2alJNNHhVTmM2R1JtT3BBMTZ3cndLTTdpSDdn?=
 =?utf-8?B?ZmQxMmNVZFFwRHZHMVZlbys2Z1BrRm1ybXZ0RXJsUTRoV3NZV1NKSVAxZ2Q5?=
 =?utf-8?B?TGkzOVBhaFFTUjlkNm83UHloU2tCMVFiRXlZRkVNaktCd0pMWXBkeExMSjRo?=
 =?utf-8?B?UmEweFVwazdoYk55ZVBIK1BRTDRFMWxpalJiank4VlZKdTYvbVBWMHRrclNl?=
 =?utf-8?B?RzRvdFprYmZYVklrNmpyTGxLU3NzcENNejFsMnUzeEF6K1BTZm1palg4MUZn?=
 =?utf-8?B?RjVIRDVJblp1TUFBcXN3UzBMeVNlTldjbXd6djcyL0RHMVJqMVFQdFdJQkdJ?=
 =?utf-8?B?T2NKYWxWckswUjIvSDdZaXJFaklQWk5PMkdzc3NwQy93U28zR2w2L2ZPUmRE?=
 =?utf-8?B?ckpadWo1QVo3Sy9STlZhRHMrcnBlQUZTYVlSZnNUOHhlM3BBQmM0VUxtdGc2?=
 =?utf-8?B?VnZCYm9YOEdVN1AxZXJwSThaN0xuNWdUb1g4R0ZLM0UxZXlQN2xjNmJDOEUv?=
 =?utf-8?B?Ti9TRkpJV3BUN00wSE9XWmg4S0RSbnNDZ1JiZlJhd1lBVWJ6Sk9uN3cxR0Jq?=
 =?utf-8?B?T3lhcXg5dDg0cWVsdFNyeStFeFE0ZkxqQURGY0Y1TTJKcEVBQmtaeCt3aXQ0?=
 =?utf-8?B?cUpPb2VQc1Uzd0tMVjF4WEFiOEl3b054dk9udDZLOVJCS01wMzFJd0VjS05G?=
 =?utf-8?B?aFIxYk5vU2sxTUUyZHdXdjlvc2wrVHVRN2x3bXVldTg5VG4rckNSMHdxVmRV?=
 =?utf-8?Q?LnzYHSApJ7KpFv/g79Tyq1tOHvldjlA7PfSgwuh?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ce1a857-98d6-409a-66cd-08d97ec3da05
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4196.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2021 18:56:29.2459
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: RRvsHpq8B/lExTyCGU/2IXSh1dzN2ig7OjnSIc6GXnc4Ph3BQf8bP19+RjJ3TdXORZEFYAI/iFk26KP0kx677A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB3398
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10116 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 bulkscore=0
 malwarescore=0 mlxscore=0 mlxlogscore=999 spamscore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109200000
 definitions=main-2109230112
X-Proofpoint-ORIG-GUID: i5Vp28g-fwtX3Jhs11LbN2SEpOqXAHBG
X-Proofpoint-GUID: i5Vp28g-fwtX3Jhs11LbN2SEpOqXAHBG
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 9/23/21 4:40 AM, Matthew Wilcox wrote:
> On Thu, Sep 23, 2021 at 01:15:16AM -0400, Kent Overstreet wrote:
>> On Thu, Sep 23, 2021 at 04:23:12AM +0100, Matthew Wilcox wrote:
>>> (compiling that list reminds me that we'll need to sort out mapcount
>>> on subpages when it comes time to do this.  ask me if you don't know
>>> what i'm talking about here.)
>>
>> I am curious why we would ever need a mapcount for just part of a page, tell me
>> more.
> 
> I would say Kirill is the expert here.  My understanding:
> 
> We have three different approaches to allocating 2MB pages today;
> anon THP, shmem THP and hugetlbfs.  Hugetlbfs can only be mapped on a
> 2MB boundary, so it has no special handling of mapcount [1].  Anon THP
> always starts out as being mapped exclusively on a 2MB boundary, but
> then it can be split by, eg, munmap().  If it is, then the mapcount in
> the head page is distributed to the subpages.
> 
> Shmem THP is the tricky one.  You might have a 2MB page in the page cache,
> but then have processes which only ever map part of it.  Or you might
> have some processes mapping it with a 2MB entry and others mapping part
> or all of it with 4kB entries.  And then someone truncates the file to
> midway through this page; we split it, and now we need to figure out what
> the mapcount should be on each of the subpages.  We handle this by using
> ->mapcount on each subpage to record how many non-2MB mappings there are
> of that specific page and using ->compound_mapcount to record how many 2MB
> mappings there are of the entire 2MB page.  Then, when we split, we just
> need to distribute the compound_mapcount to each page to make it correct.
> We also have the PageDoubleMap flag to tell us whether anybody has this
> 2MB page mapped with 4kB entries, so we can skip all the summing of 4kB
> mapcounts if nobody has done that.
> 
> [1] Mike is looking to change this, but I'm not sure where he is with it.

Not just me, but several others also interested in 'double mapping'
hugetlb pages.  We are very early in the process and have not yet got
to this level of detail.  My initial thought is that this may not be an
issue.  Although we will allow different size mappings, we will never
split the underlying huge page.
-- 
Mike Kravetz