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 9468FC2BD09 for ; Mon, 24 Jun 2024 20:51:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02F7D6B024D; Mon, 24 Jun 2024 16:51:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F21956B02CE; Mon, 24 Jun 2024 16:51:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE89A6B02E1; Mon, 24 Jun 2024 16:51:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BF74A6B024D for ; Mon, 24 Jun 2024 16:51:42 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4A8A1A399D for ; Mon, 24 Jun 2024 20:51:42 +0000 (UTC) X-FDA: 82266978444.15.39F58DA Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id CE7A540016 for ; Mon, 24 Jun 2024 20:51:38 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="dWm2Km/v"; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719262282; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bEGUJt2Mi8EMv5BNM/0nl9YsVj5hoU0o3ifiX8cToz8=; b=uhhmb/7LpW/xJjcbciK6oocPEb5F2JgAnp3wAR24ADVI7o7aQq8kV5vsx3YJjpqSRf/tOO sRHYQUG15zsN4WII7VYGfjhcfe6Z3DgwXEnfpoxQTuDVZMw3htr2T2huwGm0PEz4E2cDTE d606DF8wArU5RXvf7pLMVQ1FIZPsaGY= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="dWm2Km/v"; spf=none (imf11.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719262282; a=rsa-sha256; cv=none; b=PAzkOTHUR9swgGHPTyx14E1v3wNtfQ8x5HXsNYCQCqegpDcP9vDs9ZzUtd5Iw+9Lhr3uvc esUngnUgRC11cnzXraUVgImmlcbvoqvBfRgsrVMSzMnFkdaOZ/2eFFp4vFtzbg3Y64Zu+7 wuRV4f+fgY4wQcyyQ9Fs7fLYLBFL9go= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=bEGUJt2Mi8EMv5BNM/0nl9YsVj5hoU0o3ifiX8cToz8=; b=dWm2Km/vrBkAoRqfMMCAcSG8Mi /Om7ODTTUe8UhwCqQTtHMcIyQqKzTOev/KYejSC0w1OYV+jufL033Bg/moAfdTDUxywqVXUHPdQXC w6ugLbz+kBjjyPQ/3Oy0wa8H4rNI9wpjLaVT68iazFpdPlooVFf4LzbdGgVrM0RHzIUVbnTzwB9ul cMSuKy+sWzcEk3OFDVTP+6m8kxJ57qyHPioxOesVU8KYkG67IWbOUg+Fch295EGa2Wsu25x6s5+qH IOySklqrEJbXGm/pUQ+oiYQcnHlt2ptt7MU4hxsVLuhP6aayMQbFk3qNQ8Anxs2oVAV1JqFVqMNkX aC/48KxQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sLqez-0000000AQmx-1HtP; Mon, 24 Jun 2024 20:51:33 +0000 Date: Mon, 24 Jun 2024 21:51:33 +0100 From: Matthew Wilcox To: Shakeel Butt Cc: Yosry Ahmed , kernel test robot , Usama Arif , oe-lkp@lists.linux.dev, lkp@intel.com, Linux Memory Management List , Andrew Morton , Chengming Zhou , Nhat Pham , David Hildenbrand , "Huang, Ying" , Hugh Dickins , Johannes Weiner , Andi Kleen , linux-kernel@vger.kernel.org Subject: Re: [linux-next:master] [mm] 0fa2857d23: WARNING:at_mm/page_alloc.c:#__alloc_pages_noprof Message-ID: References: <202406241651.963e3e78-oliver.sang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CE7A540016 X-Stat-Signature: dpejh4eh3464oudzri1qkditaeq3e3zn X-Rspam-User: X-HE-Tag: 1719262298-97006 X-HE-Meta: U2FsdGVkX18JIlIYWUn1ELb9wZNb+J8FfsXhxp89pRaqHTZU/+VetCDH3qwCs6pCBHuZCuJLDI+TQumDqjLuGLaRGQrgx8W9k4XebIt9lC1VL7vvgbrCba+53Zry+005XQRtidkjWFBXbCjvY3sskJ7zXFPd4wt4lqWuoOpimbOnNQ417iC6qMEKD52OmSTlS6QsWN8FhsjkhnDs51Rk7+si3kRdm5Pzj4YCi5ZwAOg99KUrN2IfI92cvKDxs/+FIsBlfkSfZM1W4ZOisOLd090oGz2oDaxOl95iAPZ6j7gwPJflDiJ7M1uv4bICffrSHYhbgEYdnD2zCNw0aryPp0OF2xV2kyTd32I6eLGt7nMNoc+/jRhYeSnLtMMEYMTa5HzojdkzCKWgmyOGjK7TuSG3FAzCJvAGIxbOnYL7z499r3bcE3ejbXDSFpgsAQItdj3zDAG0Lw4HOlz31ah+6DyxTPOytErtTzARizPqZX0dxMl1lG5kGRU/5GcKrzd3kBaq6oDkCdZ7SCWUqiYc89ahisfeotFCKBDY8m9P09tXCTJD/63VD0nEPQZxbeYz10700iHjWLUcEW/keiQ58EMxr+VbkS7Ku/jc1YNXpama0RRxlnsoVlpqdUbyNeiL3z38qV0QM5ZrGM4txxhIzQb/n0DscHCJdEqJm3HmVOudW0fR2F/99Jz7CJt0FqmDv2m865a1u+ZcycX1X+LZGdQyr9mwHu/JZ79Th7pBkdIfYT3WUVv4mSfkYENhnuwY/qTMuALT+OL7axqOMpQsma8QJHERLEdfugMSzfADM5l0CY3YmEi7yOSYWACUuDLU1dKFljkhyPdV3ggoWUcznZtBnJEq1SoJl5UWEYbo67WQxlRasHotOhNU+YkhWxRBGCgRbTIpD+oa5en0GpXHvBDC5WG3bEN5hcLfRJy8ePWsVgZUlQVUxRFHJ37lFE1RnC2fbWmNR/C8TF64mQg IjAqKdwy EfZnGY7+GHHV3wMYLOUk3nXiwsZB2I5YvijBgDNYO6cpHOyJ8ca3LaMpVVLBbK5R+pgh6OJn6MPfyadEx9ZXf/ZvSt7SR7pkZFRyxNOSzPNlAGkO1m4ArrlRRRKuLsyKg3su+vpogCWCk0rCCbzrbGMAhmlT4GoV9IasWYLTlH1bgMQR0mMBZEQuTQsgxHoY4izXbVFmRnJJJUsZZ3tzTjRN1M3HzN0kvutMwkjmAM4XZLeoWIbljOH6wJP7KZHZecuWwarz4dWid4m3hbMk6Yhw2K3yo76j9BQJ+qhAPvOcWQ77duKQTLLM8zPNRgMAsyvNZTVHnFK6OBvYLDEJut6NscB3tM611dUfBAMkZ1zf9IV2ILZPIn70JFw== 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: List-Subscribe: List-Unsubscribe: On Mon, Jun 24, 2024 at 01:39:45PM -0700, Shakeel Butt wrote: > On Mon, Jun 24, 2024 at 08:50:45PM GMT, Matthew Wilcox wrote: > > On Mon, Jun 24, 2024 at 12:34:04PM -0700, Yosry Ahmed wrote: > > > On Mon, Jun 24, 2024 at 12:26 PM Matthew Wilcox wrote: > > > > > > > > On Mon, Jun 24, 2024 at 11:57:45AM -0700, Yosry Ahmed wrote: > > > > > On Mon, Jun 24, 2024 at 11:56 AM Matthew Wilcox wrote: > > > > > > > > > > > > On Mon, Jun 24, 2024 at 11:53:30AM -0700, Yosry Ahmed wrote: > > > > > > > After a page is swapped out during reclaim, __remove_mapping() will > > > > > > > call __delete_from_swap_cache() to replace the swap cache entry with a > > > > > > > shadow entry (which is an xa_value). > > > > > > > > > > > > Special entries are disjoint from shadow entries. Shadow entries have > > > > > > the last two bits as 01 or 11 (are congruent to 1 or 3 modulo 4). > > > > > > Special entries have values below 4096 which end in 10 (are congruent > > > > > > to 2 modulo 4). > > > > > > > > > > You are implying that we would no longer have a shadow entry for such > > > > > zero folios, because we will be storing a special entry instead. > > > > > Right? > > > > > > > > umm ... maybe I have a misunderstanding here. > > > > > > > > I'm saying that there wouldn't be a _swap_ entry here because the folio > > > > wouldn't be stored anywhere on the swap device. But there could be a > > > > _shadow_ entry. Although if the page is full of zeroes, it was probably > > > > never referenced and doesn't really need a shadow entry. > > > > > > Is it possible to have a shadow entry AND a special entry (e.g. > > > XA_ZERO_ENTRY) at the same index? This is what would be required to > > > maintain the current behavior (assuming we really need the shadow > > > entries for such zeroed folios). > > > > No, just like it's not possible to have a swap entry and a shadow entry > > at the same location. You have to choose. But the zero entry is an > > alternative to the swap entry, not the shadow entry. > > > > As I understand the swap cache, at the moment, you can have four > > possible results from a lookup: > > > > - NULL > > - a swap entry > > - a shadow entry > > - a folio > > > > Do I have that wrong? > > I don't think we have swap entry in the swapcache (underlying xarray). > The swap entry is used as an index to find the folio or shadow entry. Ah. I think I understand the procedure now. We store a swap entry in the page table entry. That tells us both where in the swap cache the folio might be found, and where in the swap device the data can be found (because there is a very simple calculation for both). If the folio is not present, then there's a shadow entry which summarises the LRU information that would be stored in the folio had it not been evicted from the swapcache. We can't know at the point where we unmap the page whether it's full of zeroes or not, because we can't afford to scan its contents. At the point where we decide to swap out the folio, we can afford to make that decision because the cost of doing the I/O is high enough. So the question is whether we can afford to throw away the shadow information and just store the information that this was a zero entry. I think we can, but it is a more bold proposal than I realised I was making.