Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 31 Jan 2024 13:58:26 -0800 | From | Luis Chamberlain <> | Subject | Re: [PATCH 1/2] test_xarray: add tests for advanced multi-index use |
| |
On Fri, Jan 26, 2024 at 08:32:28PM +0000, Matthew Wilcox wrote: > On Fri, Jan 26, 2024 at 12:04:44PM -0800, Luis Chamberlain wrote: > > > We have a perfectly good system for "relaxing": > > > > > > xas_for_each_marked(&xas, page, end, PAGECACHE_TAG_DIRTY) { > > > xas_set_mark(&xas, PAGECACHE_TAG_TOWRITE); > > > if (++tagged % XA_CHECK_SCHED) > > > continue; > > > > > > xas_pause(&xas); > > > xas_unlock_irq(&xas); > > > cond_resched(); > > > xas_lock_irq(&xas); > > > } > > > > And yet we can get a soft lockup with order 20 (1,048,576 entries), > > granted busy looping over 1 million entries is insane, but it seems it > > the existing code may not be enough to avoid the soft lockup. Also > > cond_resched() may be eventually removed [0]. > > what? you're in charge of when you sleep. you can do this: > > unsigned i = 0; > rcu_read_lock(); > xas_for_each(...) { > ... > if (iter++ % XA_CHECK_SCHED) > continue; > xas_pause(); > rcu_read_unlock(); > rcu_read_lock(); > } > rcu_read_unlock(); > > and that will get rid of the rcu warnings. right?
The RCU warning was due to my getting an try call missing an RCU lock, I fixed that. The pending issue was a soft lockup that I get on low end systems testing test_xarray with higher order but after testing on a 2 vcpus with only 2 GiB of RAM I cannot reproduce so we can address this later. I forget the exact type of low end system I tested this on... but anyway I can't reproduce now. I suspect it may have been similar to the issue 0-day had found long ago and you noted an overloaded system [0]
[0] https://lore.kernel.org/all/20190306120843.GI13380@bombadil.infradead.org/
Luis
| ![\](/images/icornerr.gif) |