Re: [PATCH 4/8] xfs: use memalloc_nofs_{save,restore} instead of memalloc_noio*

here - implicit GFP_NOFS context. > > Changes since v1 > - s@memalloc_noio_restore@memalloc_nofs_restore@ in _xfs_buf_map_pages > as per Brian Foster > > Signed-off-by: Michal Hocko <mho...@suse.com> Not a xfs expert, but seems correct. Acked-by: Vlastimil Babka <

Re: [PATCH 3/8] mm: introduce memalloc_nofs_{save,restore} API

On 01/09/2017 02:42 PM, Michal Hocko wrote: > On Mon 09-01-17 14:04:21, Vlastimil Babka wrote: > [...] >>> +static inline unsigned int memalloc_nofs_save(void) >>> +{ >>> + unsigned int flags = current->flags & PF_MEMALLOC_NOFS; >>>

Re: [PATCH 3/8] mm: introduce memalloc_nofs_{save,restore} API

On 01/06/2017 03:11 PM, Michal Hocko wrote: > From: Michal Hocko > > GFP_NOFS context is used for the following 5 reasons currently > - to prevent from deadlocks when the lock held by the allocation > context would be needed during the memory reclaim > - to

Re: [PATCH 1/8] lockdep: allow to disable reclaim lockup detection

es. This would prevent from abusing GFP_NOFS > flag which has a runtime effect even on configurations which have > lockdep disabled. > > Introduce __GFP_NOLOCKDEP flag which tells the lockdep gfp tracking to > skip the current allocation request. > > While we are at it also make s

Re: [PATCH 2/8] xfs: abstract PF_FSTRANS to PF_MEMALLOC_NOFS

s uses the flag directly > anyway. > > This patch doesn't introduce any functional change. > > Signed-off-by: Michal Hocko <mho...@suse.com> > Reviewed-by: Brian Foster <bfos...@redhat.com> Acked-by: Vlastimil Babka <vba...@suse.cz> A nit: > --- a/include/linux/s

Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache

at as of >> yet, >> >> Thanks, >> -Eli >> >> On Fri, Nov 18, 2016 at 6:54 AM, Tetsuo Handa >> <penguin-ker...@i-love.sakura.ne.jp> wrote: >>> On 2016/11/18 6:49, Vlastimil Babka wrote: >>>> On 11/16/2016 02:39 PM, E V wrote: >

Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache

On 11/16/2016 02:39 PM, E V wrote: > System panic'd overnight running 4.9rc5 & rsync. Attached a photo of > the stack trace, and the 38 call traces in a 2 minute window shortly > before, to the bugzilla case for those not on it's e-mail list: > > https://bugzilla.kernel.org/show_bug.cgi?id=186671

Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache

bash > [737778.731207] [15150] 0 15150 3309 678 10 3 > 57 0 run_mirror.sh > [737778.731256] [24296] 0 24296 1450 139 8 3 > 23 0 flock > [737778.731302] [24297] 0 24297 9576 622

Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache

On 11/04/2016 03:13 PM, E V wrote: > After the system panic'd yesterday I booted back into 4.8.4 and > restarted the rsync's. I'm away on vacation next week, so when I get > back I'll get rc4 or rc5 and try again. In the mean time here's data > from the system running 4.8.4 without problems for

Re: [Bug 186671] New: OOM on system with just rsync running 32GB of ram 30GB of pagecache

On 11/03/2016 07:53 PM, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). +CC also btrfs just in case it's a problem in page reclaim there > On Wed, 02 Nov 2016 13:02:39 + bugzilla-dae...@bugzilla.kernel.org wrote:

Re: [PATCH 0/2] btrfs: fortification for GFP_NOFS allocations

On 08/19/2015 08:17 PM, Chris Mason wrote: On Wed, Aug 19, 2015 at 02:17:39PM +0200, mho...@kernel.org wrote: Hi, these two patches were sent as a part of a larger RFC which aims at allowing GFP_NOFS allocations to fail to help sort out memory reclaim issues bound to the current behavior