On Tue, Aug 13, 2019 at 12:35:49PM -0400, Mikulas Patocka wrote:
>
>
> On Sat, 10 Aug 2019, Dave Chinner wrote:
>
> > No, you misunderstand. I'm talking about blocking kswapd being
> > wrong. i.e. Blocking kswapd in shrinkers causes problems
> > because th ememory reclaim code does not expect
On Sat, 10 Aug 2019, Dave Chinner wrote:
> No, you misunderstand. I'm talking about blocking kswapd being
> wrong. i.e. Blocking kswapd in shrinkers causes problems
> because th ememory reclaim code does not expect kswapd to be
> arbitrarily delayed by waiting on IO. We've had this problem
On Fri, Aug 09, 2019 at 07:30:00AM -0400, Mikulas Patocka wrote:
>
>
> On Fri, 9 Aug 2019, Dave Chinner wrote:
>
> > And, FWIW, there's an argument to be made here that the underlying
> > bug is dm_bufio_shrink_scan() blocking kswapd by waiting on IO
> > completions while holding a mutex that
On Fri, 9 Aug 2019, Dave Chinner wrote:
> And, FWIW, there's an argument to be made here that the underlying
> bug is dm_bufio_shrink_scan() blocking kswapd by waiting on IO
> completions while holding a mutex that other IO-level reclaim
> contexts require to make progress.
>
> Cheers,
>
>
On Thu, Aug 08, 2019 at 05:50:10AM -0400, Mikulas Patocka wrote:
> A deadlock with this stacktrace was observed.
>
> The obvious problem here is that in the call chain
> xfs_vm_direct_IO->__blockdev_direct_IO->do_blockdev_direct_IO->kmem_cache_alloc
>
> we do a GFP_KERNEL allocation while we
On Thu, 8 Aug 2019, Matthew Wilcox wrote:
> On Thu, Aug 08, 2019 at 05:50:10AM -0400, Mikulas Patocka wrote:
> > A deadlock with this stacktrace was observed.
> >
> > The obvious problem here is that in the call chain
> >
Hi Mikulas,
This seemed not issue on mainline, mutex in dm_bufio_shrink_count() had
been removed from mainline.
Thanks,
Junxiao.
On 8/8/19 2:50 AM, Mikulas Patocka wrote:
A deadlock with this stacktrace was observed.
The obvious problem here is that in the call chain
On Thu, Aug 08, 2019 at 05:50:10AM -0400, Mikulas Patocka wrote:
> A deadlock with this stacktrace was observed.
>
> The obvious problem here is that in the call chain
> xfs_vm_direct_IO->__blockdev_direct_IO->do_blockdev_direct_IO->kmem_cache_alloc
>
> we do a GFP_KERNEL allocation while we
A deadlock with this stacktrace was observed.
The obvious problem here is that in the call chain
xfs_vm_direct_IO->__blockdev_direct_IO->do_blockdev_direct_IO->kmem_cache_alloc
we do a GFP_KERNEL allocation while we are in a filesystem driver and in a
block device driver.
This patch changes
