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 6028EC433FE for ; Wed, 19 Oct 2022 22:46:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F4546B0071; Wed, 19 Oct 2022 18:46:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A3EF6B0073; Wed, 19 Oct 2022 18:46:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46BC86B0074; Wed, 19 Oct 2022 18:46:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 33D486B0071 for ; Wed, 19 Oct 2022 18:46:22 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DCE0C1A0EC2 for ; Wed, 19 Oct 2022 22:46:21 +0000 (UTC) X-FDA: 80039184162.18.50B56AA Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by imf12.hostedemail.com (Postfix) with ESMTP id 819034000C for ; Wed, 19 Oct 2022 22:46:21 +0000 (UTC) Received: by mail-pf1-f181.google.com with SMTP id d10so18595863pfh.6 for ; Wed, 19 Oct 2022 15:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lI2fXM/HJXDbYYypU85JMv6ava4twJsKV3cSTxnNcQY=; b=Hn/WHkbDdzDa7BHtb7M7h3naX+60Xt0Ef5iKKMgjngqnSuxASV00FDy43XLbMU/DLh e733KyKPYpurJ2HDGYOvqdxYEfcODVsuMoPmMl1tNTVKOgS8X/zXuThaivWYHkA//OAa i3hl+ZuR8OVwbTyFwqvYEseevcsWJIQWv49QBs4BjCQ6yML75LQcrAPoniSiWC9HAFbi F/9UPkjZV9Ke2OEmRQ+z20KBBflqB+ZPSaDgtCS6InpNJt/kyXl8VqZGK/uTb83Dj7m7 QW9U49wWFm8SkbHYlLAGWJ6rb2jnTc9/i8U7uvrz4DusdJOA5UmsIhyDf+G7OCuXh2k2 iqSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lI2fXM/HJXDbYYypU85JMv6ava4twJsKV3cSTxnNcQY=; b=GnlINuTEDl+QYhxDboDCwg7JYwJcT1MnuRVTfGJo1kmzdHv1pP79OC0R8r0XtmRuuN oZyOU+8n+HQ+xKqSFCoG8YMF6hjNWsp+ycaJthcy76JthzpmH+czRNMQhbBf53vms6jz F74JcaNMY85wMNWmVs1b/s+Uz9tO0DVNHlw5m4k8p5F0mIDIESUDvDxDwUfDgAc6AJMo TYpO4IVuU8La7LNe7yY8KiWYHHL/cptDtBycE6AC//DO3uSHYbUGwhIn0TpSnANpcHUY lFS5jrdxra4DQdFEymekCfdZ/8zG7PVcpwzh7I0/zSFEATfybA4MO9dh6SVRTGYVYDW2 8I8Q== X-Gm-Message-State: ACrzQf0rMLmEngmOhYdIQrpbzj/lCzUf8Dbl74GfyMONsUb7e30nthSe EMwYkFSgCa+up3jWm9glgqKgiA== X-Google-Smtp-Source: AMsMyM50N5TT8WzQ8RsGq/gj5TUOb9aOsUDmf1RLzeffdvNV6L7swf9eC4V13nmYqTZ185C40SsHqQ== X-Received: by 2002:a63:540b:0:b0:43c:8ce9:2800 with SMTP id i11-20020a63540b000000b0043c8ce92800mr8974754pgb.481.1666219580444; Wed, 19 Oct 2022 15:46:20 -0700 (PDT) Received: from dread.disaster.area (pa49-181-106-210.pa.nsw.optusnet.com.au. [49.181.106.210]) by smtp.gmail.com with ESMTPSA id i17-20020a170902c95100b00181e55d02dcsm11242789pla.139.2022.10.19.15.46.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Oct 2022 15:46:19 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1olHpI-0041g7-RW; Thu, 20 Oct 2022 09:46:16 +1100 Date: Thu, 20 Oct 2022 09:46:16 +1100 From: Dave Chinner To: Matthew Wilcox Cc: Zhaoyang Huang , "zhaoyang.huang" , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, ke.wang@unisoc.com, steve.kang@unisoc.com, baocong.liu@unisoc.com, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH] mm: move xa forward when run across zombie page Message-ID: <20221019224616.GP2703033@dread.disaster.area> References: <1665725448-31439-1-git-send-email-zhaoyang.huang@unisoc.com> <20221018223042.GJ2703033@dread.disaster.area> <20221019220424.GO2703033@dread.disaster.area> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221019220424.GO2703033@dread.disaster.area> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666219581; 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=lI2fXM/HJXDbYYypU85JMv6ava4twJsKV3cSTxnNcQY=; b=zOaJkDZivttj9EW5nfU0G8qqKV/jBxelSwtAyQaQwqLuvdy4HlNj3aK5oSIzyEF5gTin1E vFIHoPNZe3NeOJxTEofNCzCTnhXH42IcFqpQVI5KIgLRB3oLFRvB6NrzSFh0DIVwj/Bxs7 bVPpzzNrSqor3ZEtHHNzBQ9A2F4lJ+E= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b="Hn/WHkbD"; spf=none (imf12.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 209.85.210.181) smtp.mailfrom=david@fromorbit.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666219581; a=rsa-sha256; cv=none; b=fqxzh1Oei3YZ4mGU7NBsqN6/VXDRRB2B3MHu2rRcEPX3zFwE7+lv2c/p97jrZD0wsxhy92 UJlDZdwUhIWitc9K3Q59vNJ1zZPTTu0EWM+K4I5qt7sPDBXwI+Jh07z5h21tN7Q5nee8C8 dSbhHGGCeMc6CnjrQ56Rrpfm0OaXXx4= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 819034000C X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=fromorbit-com.20210112.gappssmtp.com header.s=20210112 header.b="Hn/WHkbD"; spf=none (imf12.hostedemail.com: domain of david@fromorbit.com has no SPF policy when checking 209.85.210.181) smtp.mailfrom=david@fromorbit.com; dmarc=none X-Stat-Signature: xyjq893ttnbckiy5gk7d9e8day98m8n5 X-HE-Tag: 1666219581-859559 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 Thu, Oct 20, 2022 at 09:04:24AM +1100, Dave Chinner wrote: > On Wed, Oct 19, 2022 at 04:23:10PM +0100, Matthew Wilcox wrote: > > On Wed, Oct 19, 2022 at 09:30:42AM +1100, Dave Chinner wrote: > > > This is reading and writing the same amount of file data at the > > > application level, but once the data has been written and kicked out > > > of the page cache it seems to require an awful lot more read IO to > > > get it back to the application. i.e. this looks like mmap() is > > > readahead thrashing severely, and eventually it livelocks with this > > > sort of report: > > > > > > [175901.982484] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: > > > [175901.985095] rcu: Tasks blocked on level-1 rcu_node (CPUs 0-15): P25728 > > > [175901.987996] (detected by 0, t=97399871 jiffies, g=15891025, q=1972622 ncpus=32) > > > [175901.991698] task:test_write state:R running task stack:12784 pid:25728 ppid: 25696 flags:0x00004002 > > > [175901.995614] Call Trace: > > > [175901.996090] > > > [175901.996594] ? __schedule+0x301/0xa30 > > > [175901.997411] ? sysvec_apic_timer_interrupt+0xb/0x90 > > > [175901.998513] ? sysvec_apic_timer_interrupt+0xb/0x90 > > > [175901.999578] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 > > > [175902.000714] ? xas_start+0x53/0xc0 > > > [175902.001484] ? xas_load+0x24/0xa0 > > > [175902.002208] ? xas_load+0x5/0xa0 > > > [175902.002878] ? __filemap_get_folio+0x87/0x340 > > > [175902.003823] ? filemap_fault+0x139/0x8d0 > > > [175902.004693] ? __do_fault+0x31/0x1d0 > > > [175902.005372] ? __handle_mm_fault+0xda9/0x17d0 > > > [175902.006213] ? handle_mm_fault+0xd0/0x2a0 > > > [175902.006998] ? exc_page_fault+0x1d9/0x810 > > > [175902.007789] ? asm_exc_page_fault+0x22/0x30 > > > [175902.008613] > > > > > > Given that filemap_fault on XFS is probably trying to map large > > > folios, I do wonder if this is a result of some kind of race with > > > teardown of a large folio... > > > > It doesn't matter whether we're trying to map a large folio; it > > matters whether a large folio was previously created in the cache. > > Through the magic of readahead, it may well have been. I suspect > > it's not teardown of a large folio, but splitting. Removing a > > page from the page cache stores to the pointer in the XArray > > first (either NULL or a shadow entry), then decrements the refcount. > > > > We must be observing a frozen folio. There are a number of places > > in the MM which freeze a folio, but the obvious one is splitting. > > That looks like this: > > > > local_irq_disable(); > > if (mapping) { > > xas_lock(&xas); > > (...) > > if (folio_ref_freeze(folio, 1 + extra_pins)) { > > But the lookup is not doing anything to prevent the split on the > frozen page from making progress, right? It's not holding any folio > references, and it's not holding the mapping tree lock, either. So > how does the lookup in progress prevent the page split from making > progress? > > > > So one way to solve this might be to try to take the xa_lock on > > failure to get the refcount. Otherwise a high-priority task > > might spin forever without a low-priority task getting the chance > > to finish the work being done while the folio is frozen. > > IIUC, then you are saying that there is a scheduling priority > inversion because the lookup failure looping path doesn't yeild the > CPU? > > If so, how does taking the mapping tree spin lock on failure cause > the looping task to yield the CPU and hence allow the folio split to > make progress? > > Also, AFAICT, the page split has disabled local interrupts, so it > should effectively be running with preemption disabled as it has > turned off the mechanism the scheduler can use to preempt it. The > page split can't sleep, either, because it holds the mapping tree > lock. Hence I can't see how a split-in-progress can be preempted in > teh first place to cause a priority inversion livelock like this... > > > ie this: > > > > diff --git a/mm/filemap.c b/mm/filemap.c > > index 08341616ae7a..ca0eed80580f 100644 > > --- a/mm/filemap.c > > +++ b/mm/filemap.c > > @@ -1860,8 +1860,13 @@ static void *mapping_get_entry(struct address_space *mapping, pgoff_t index) > > if (!folio || xa_is_value(folio)) > > goto out; > > > > - if (!folio_try_get_rcu(folio)) > > + if (!folio_try_get_rcu(folio)) { > > + unsigned long flags; > > + > > + xas_lock_irqsave(&xas, flags); > > + xas_unlock_irqrestore(&xas, flags); > > goto repeat; > > + } As I suspected, this change did not prevent the livelock. It reproduced after just 650 test iterations (a few minutes) with this change in place. > I would have thought: > > if (!folio_try_get_rcu(folio)) { > rcu_read_unlock(); > cond_resched(); > rcu_read_lock(); > goto repeat; > } > > Would be the right way to yeild the CPU to avoid priority > inversion related livelocks here... I'm now trying this just to provide a data point that actually yeilding the CPU avoids the downstream effects of the livelock (i.e. RCU grace period never expires, system eventually dies...). Maybe it will avoid the livelock altogether, but I still don't understand how huge page splitting would be getting preempted in the first place... Cheers, Dave. -- Dave Chinner david@fromorbit.com