From: Olivier Langlois <olivier@trillion01.com>
To: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <djwong@kernel.org>, Stefan Roesch <shr@fb.com>,
io-uring@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
david@fromorbit.com, hch@infradead.org
Subject: Re: [PATCH v6 04/16] iomap: Add flags parameter to iomap_page_create()
Date: Wed, 01 Jun 2022 13:29:55 -0400 [thread overview]
Message-ID: <32fa2fa1db1adcc3c60974fa84a88c74aad82cae.camel@trillion01.com> (raw)
In-Reply-To: <20220601082131.rem4qaqabu4ktofl@quack3.lan>
On Wed, 2022-06-01 at 10:21 +0200, Jan Kara wrote:
> > I have a question that is a bit offtopic but since it is concerning
> > GFP
> > flags and this is what is discussed here maybe a participant will
> > kindly give me some hints about this mystery that has burned me for
> > so
> > long...
> >
> > Why does out_of_memory() requires GFP_FS to kill a process? AFAIK,
> > no
> > filesystem-dependent operations are needed to kill a process...
>
> AFAIK it is because without GFP_FS, the chances for direct reclaim
> are
> fairly limited so we are not sure whether the machine is indeed out
> of
> memory or whether it is just that we need to reclaim from fs pools to
> free
> up memory.
>
> Honza
Jan,
thx a lot for this lead. I will study it further. Your answer made me
realized that the meaning of direct reclaim was not crystal clear to
me. I'll return to my Bovet & Cesati book to clear that out (That is
probably the book in my bookshelf that I have read the most).
After having sending out my question, I have came up with another
possible explanation...
Maybe it is not so much to send the killing signal to the oom victim
that requires GFP_FS but maybe the trouble the condition is avoiding is
the oom victim process trying to return memory to VFS as it exits while
VFS is busy waiting for its allocation request to succeed...
next prev parent reply other threads:[~2022-06-01 18:24 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 17:38 [PATCH v6 00/16] io-uring/xfs: support async buffered writes Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 01/16] mm: Move starting of background writeback into the main balancing loop Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 02/16] mm: Move updates of dirty_exceeded into one place Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 03/16] mm: Add balance_dirty_pages_ratelimited_flags() function Stefan Roesch
2022-05-31 6:52 ` Christoph Hellwig
2022-05-26 17:38 ` [PATCH v6 04/16] iomap: Add flags parameter to iomap_page_create() Stefan Roesch
2022-05-26 18:25 ` Darrick J. Wong
2022-05-26 18:43 ` Stefan Roesch
2022-06-01 0:34 ` Olivier Langlois
2022-06-01 8:21 ` Jan Kara
2022-06-01 17:29 ` Olivier Langlois [this message]
2022-05-31 6:54 ` Christoph Hellwig
2022-05-31 18:12 ` Stefan Roesch
2022-06-01 17:56 ` Darrick J. Wong
2022-05-26 17:38 ` [PATCH v6 05/16] iomap: Add async buffered write support Stefan Roesch
2022-05-26 18:42 ` Darrick J. Wong
2022-05-26 22:37 ` Dave Chinner
2022-05-27 8:42 ` Jan Kara
2022-05-27 22:52 ` Dave Chinner
2022-05-31 7:55 ` Jan Kara
2022-05-31 6:58 ` Christoph Hellwig
2022-05-26 17:38 ` [PATCH v6 06/16] fs: Add check for async buffered writes to generic_write_checks Stefan Roesch
2022-05-31 6:59 ` Christoph Hellwig
2022-05-26 17:38 ` [PATCH v6 07/16] fs: add __remove_file_privs() with flags parameter Stefan Roesch
2022-05-31 7:00 ` Christoph Hellwig
2022-05-26 17:38 ` [PATCH v6 08/16] fs: Split off inode_needs_update_time and __file_update_time Stefan Roesch
2022-05-31 7:01 ` Christoph Hellwig
2022-05-31 19:02 ` Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 09/16] fs: Add async write file modification handling Stefan Roesch
2022-05-31 7:01 ` Christoph Hellwig
2022-05-26 17:38 ` [PATCH v6 10/16] fs: Optimization for concurrent file time updates Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 11/16] io_uring: Add support for async buffered writes Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 12/16] io_uring: Add tracepoint for short writes Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 13/16] xfs: Specify lockmode when calling xfs_ilock_for_iomap() Stefan Roesch
2022-05-31 7:03 ` Christoph Hellwig
2022-05-26 17:38 ` [PATCH v6 14/16] xfs: Change function signature of xfs_ilock_iocb() Stefan Roesch
2022-05-31 7:04 ` Christoph Hellwig
2022-05-31 19:15 ` Stefan Roesch
2022-06-01 5:26 ` Christoph Hellwig
2022-06-01 17:15 ` Stefan Roesch
2022-05-26 17:38 ` [PATCH v6 15/16] xfs: Add async buffered write support Stefan Roesch
2022-05-31 7:05 ` Christoph Hellwig
2022-05-26 17:38 ` [PATCH v6 16/16] xfs: Enable " Stefan Roesch
2022-05-31 7:05 ` Christoph Hellwig
2022-05-31 19:18 ` Stefan Roesch
2022-05-26 18:12 ` [PATCH v6 00/16] io-uring/xfs: support async buffered writes Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=32fa2fa1db1adcc3c60974fa84a88c74aad82cae.camel@trillion01.com \
--to=olivier@trillion01.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=kernel-team@fb.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=shr@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.