On Fri, Oct 23, 2020 at 4:16 PM Matthew Wilcox willy@infradead.org wrote:
On Fri, Oct 23, 2020 at 02:21:15PM +0200, Daniel Vetter wrote:
Note that unlike fs_reclaim_acquire/release gfpflags_allow_blocking does not consult the PF_MEMALLOC flags. But there is no flag equivalent for GFP_NOWAIT, hence this check can't go wrong due to memalloc_no*_save/restore contexts.
I have a patch series that adds memalloc_nowait_save/restore.
tbh this was a typoed git send-email, but thanks for the heads-up, I'll adjust the patch accordingly.
Cheers, Daniel
https://lore.kernel.org/linux-mm/20200625113122.7540-7-willy@infradead.org/
On Fri, Oct 23, 2020 at 4:37 PM Daniel Vetter daniel.vetter@ffwll.ch wrote:
On Fri, Oct 23, 2020 at 4:16 PM Matthew Wilcox willy@infradead.org wrote:
On Fri, Oct 23, 2020 at 02:21:15PM +0200, Daniel Vetter wrote:
Note that unlike fs_reclaim_acquire/release gfpflags_allow_blocking does not consult the PF_MEMALLOC flags. But there is no flag equivalent for GFP_NOWAIT, hence this check can't go wrong due to memalloc_no*_save/restore contexts.
I have a patch series that adds memalloc_nowait_save/restore.
tbh this was a typoed git send-email, but thanks for the heads-up, I'll adjust the patch accordingly.
On 2nd thought I think your patch should update gfpflags_allow_blocking to take into account the new ->memalloc_nowait flag you're adding. I'll comment over there in that thread. -Daniel
https://lore.kernel.org/linux-mm/20200625113122.7540-7-willy@infradead.org/
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
dri-devel@lists.freedesktop.org
-
Daniel Vetter