All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Richard Weinberger <richard@nod.at>,
	LKML <linux-kernel@vger.kernel.org>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Bob Peterson <rpeterso@redhat.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	linux-mtd@lists.infradead.org, linux-ext4@vger.kernel.org,
	cluster-devel@redhat.com, linux-nfs@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: vmalloc with GFP_NOFS
Date: Wed, 25 Apr 2018 11:25:09 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1804251114120.11848@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20180425144557.GD17484@dhcp22.suse.cz>



On Wed, 25 Apr 2018, Michal Hocko wrote:

> On Wed 25-04-18 08:43:32, Mikulas Patocka wrote:
> > 
> > 
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > 
> > > On Tue 24-04-18 19:17:12, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > > 
> > > > > > So in a perfect world a filesystem calls memalloc_nofs_save/restore and
> > > > > > always uses GFP_KERNEL for kmalloc/vmalloc?
> > > > > 
> > > > > Exactly! And in a dream world those memalloc_nofs_save act as a
> > > > > documentation of the reclaim recursion documentation ;)
> > > > > -- 
> > > > > Michal Hocko
> > > > > SUSE Labs
> > > > 
> > > > BTW. should memalloc_nofs_save and memalloc_noio_save be merged into just 
> > > > one that prevents both I/O and FS recursion?
> > > 
> > > Why should FS usage stop IO altogether?
> > 
> > Because the IO may reach loop and loop may redirect it to the same 
> > filesystem that is running under memalloc_nofs_save and deadlock.
> 
> So what is the difference with the current GFP_NOFS?

My point is that filesystems should use GFP_NOIO too. If 
alloc_pages(GFP_NOFS) issues some random I/O to some block device, the I/O 
may be end up being redirected (via block loop device) to the filesystem 
that is calling alloc_pages(GFP_NOFS).

> > > > memalloc_nofs_save allows submitting bios to I/O stack and the bios 
> > > > created under memalloc_nofs_save could be sent to the loop device and the 
> > > > loop device calls the filesystem...
> > > 
> > > Don't those use NOIO context?
> > 
> > What do you mean?
> 
> That the loop driver should make sure it will not recurse. The scope API
> doesn't add anything new here.

The loop driver doesn't recurse. The loop driver will add the request to a 
queue and wake up a thread that processes it. But if the request queue is 
full, __get_request will wait until the loop thread finishes processing 
some other request.

It doesn't recurse, but it waits until the filesystem makes some progress.

Mikulas

WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Richard Weinberger <richard@nod.at>,
	LKML <linux-kernel@vger.kernel.org>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Bob Peterson <rpeterso@redhat.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	linux-mtd@lists.infradead.org, linux-ext4@vger.k
Subject: Re: vmalloc with GFP_NOFS
Date: Wed, 25 Apr 2018 11:25:09 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1804251114120.11848@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20180425144557.GD17484@dhcp22.suse.cz>



On Wed, 25 Apr 2018, Michal Hocko wrote:

> On Wed 25-04-18 08:43:32, Mikulas Patocka wrote:
> > 
> > 
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > 
> > > On Tue 24-04-18 19:17:12, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > > 
> > > > > > So in a perfect world a filesystem calls memalloc_nofs_save/restore and
> > > > > > always uses GFP_KERNEL for kmalloc/vmalloc?
> > > > > 
> > > > > Exactly! And in a dream world those memalloc_nofs_save act as a
> > > > > documentation of the reclaim recursion documentation ;)
> > > > > -- 
> > > > > Michal Hocko
> > > > > SUSE Labs
> > > > 
> > > > BTW. should memalloc_nofs_save and memalloc_noio_save be merged into just 
> > > > one that prevents both I/O and FS recursion?
> > > 
> > > Why should FS usage stop IO altogether?
> > 
> > Because the IO may reach loop and loop may redirect it to the same 
> > filesystem that is running under memalloc_nofs_save and deadlock.
> 
> So what is the difference with the current GFP_NOFS?

My point is that filesystems should use GFP_NOIO too. If 
alloc_pages(GFP_NOFS) issues some random I/O to some block device, the I/O 
may be end up being redirected (via block loop device) to the filesystem 
that is calling alloc_pages(GFP_NOFS).

> > > > memalloc_nofs_save allows submitting bios to I/O stack and the bios 
> > > > created under memalloc_nofs_save could be sent to the loop device and the 
> > > > loop device calls the filesystem...
> > > 
> > > Don't those use NOIO context?
> > 
> > What do you mean?
> 
> That the loop driver should make sure it will not recurse. The scope API
> doesn't add anything new here.

The loop driver doesn't recurse. The loop driver will add the request to a 
queue and wake up a thread that processes it. But if the request queue is 
full, __get_request will wait until the loop thread finishes processing 
some other request.

It doesn't recurse, but it waits until the filesystem makes some progress.

Mikulas

WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] vmalloc with GFP_NOFS
Date: Wed, 25 Apr 2018 11:25:09 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1804251114120.11848@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <20180425144557.GD17484@dhcp22.suse.cz>



On Wed, 25 Apr 2018, Michal Hocko wrote:

> On Wed 25-04-18 08:43:32, Mikulas Patocka wrote:
> > 
> > 
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > 
> > > On Tue 24-04-18 19:17:12, Mikulas Patocka wrote:
> > > > 
> > > > 
> > > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > > > 
> > > > > > So in a perfect world a filesystem calls memalloc_nofs_save/restore and
> > > > > > always uses GFP_KERNEL for kmalloc/vmalloc?
> > > > > 
> > > > > Exactly! And in a dream world those memalloc_nofs_save act as a
> > > > > documentation of the reclaim recursion documentation ;)
> > > > > -- 
> > > > > Michal Hocko
> > > > > SUSE Labs
> > > > 
> > > > BTW. should memalloc_nofs_save and memalloc_noio_save be merged into just 
> > > > one that prevents both I/O and FS recursion?
> > > 
> > > Why should FS usage stop IO altogether?
> > 
> > Because the IO may reach loop and loop may redirect it to the same 
> > filesystem that is running under memalloc_nofs_save and deadlock.
> 
> So what is the difference with the current GFP_NOFS?

My point is that filesystems should use GFP_NOIO too. If 
alloc_pages(GFP_NOFS) issues some random I/O to some block device, the I/O 
may be end up being redirected (via block loop device) to the filesystem 
that is calling alloc_pages(GFP_NOFS).

> > > > memalloc_nofs_save allows submitting bios to I/O stack and the bios 
> > > > created under memalloc_nofs_save could be sent to the loop device and the 
> > > > loop device calls the filesystem...
> > > 
> > > Don't those use NOIO context?
> > 
> > What do you mean?
> 
> That the loop driver should make sure it will not recurse. The scope API
> doesn't add anything new here.

The loop driver doesn't recurse. The loop driver will add the request to a 
queue and wake up a thread that processes it. But if the request queue is 
full, __get_request will wait until the loop thread finishes processing 
some other request.

It doesn't recurse, but it waits until the filesystem makes some progress.

Mikulas



  reply	other threads:[~2018-04-25 15:25 UTC|newest]

Thread overview: 127+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24 16:27 vmalloc with GFP_NOFS Michal Hocko
2018-04-24 16:27 ` [Cluster-devel] " Michal Hocko
2018-04-24 16:27 ` Michal Hocko
2018-04-24 16:27 ` Michal Hocko
2018-04-24 16:46 ` Mikulas Patocka
2018-04-24 16:46   ` [Cluster-devel] " Mikulas Patocka
2018-04-24 16:46   ` Mikulas Patocka
2018-04-24 16:55   ` Michal Hocko
2018-04-24 16:55     ` [Cluster-devel] " Michal Hocko
2018-04-24 16:55     ` Michal Hocko
2018-04-24 17:05     ` Mikulas Patocka
2018-04-24 17:05       ` [Cluster-devel] " Mikulas Patocka
2018-04-24 17:05       ` Mikulas Patocka
2018-04-24 18:35 ` Theodore Y. Ts'o
2018-04-24 18:35   ` [Cluster-devel] " Theodore Y. Ts'o
2018-04-24 18:35   ` Theodore Y. Ts'o
2018-04-24 19:25   ` Michal Hocko
2018-04-24 19:25     ` [Cluster-devel] " Michal Hocko
2018-04-24 19:25     ` Michal Hocko
2018-05-09 13:42     ` Michal Hocko
2018-05-09 13:42       ` [Cluster-devel] " Michal Hocko
2018-05-09 13:42       ` Michal Hocko
2018-05-09 14:13       ` David Sterba
2018-05-09 14:13         ` [Cluster-devel] " David Sterba
2018-05-09 14:13         ` David Sterba
2018-05-09 15:13       ` Darrick J. Wong
2018-05-09 15:13         ` [Cluster-devel] " Darrick J. Wong
2018-05-09 15:13         ` Darrick J. Wong
2018-05-09 16:24         ` Mike Rapoport
2018-05-09 16:24           ` [Cluster-devel] " Mike Rapoport
2018-05-09 16:24           ` Mike Rapoport
2018-05-09 21:06           ` Michal Hocko
2018-05-09 21:06             ` [Cluster-devel] " Michal Hocko
2018-05-09 21:06             ` Michal Hocko
2018-05-09 21:04         ` Michal Hocko
2018-05-09 21:04           ` [Cluster-devel] " Michal Hocko
2018-05-09 21:04           ` Michal Hocko
2018-05-09 22:02           ` Darrick J. Wong
2018-05-09 22:02             ` [Cluster-devel] " Darrick J. Wong
2018-05-09 22:02             ` Darrick J. Wong
2018-05-10  5:58             ` Michal Hocko
2018-05-10  5:58               ` [Cluster-devel] " Michal Hocko
2018-05-10  5:58               ` Michal Hocko
2018-05-10  7:18               ` Michal Hocko
2018-05-10  7:18                 ` [Cluster-devel] " Michal Hocko
2018-05-10  7:18                 ` Michal Hocko
2018-05-24 11:43   ` [PATCH] doc: document scope NOFS, NOIO APIs Michal Hocko
2018-05-24 11:43     ` Michal Hocko
2018-05-24 14:33     ` Shakeel Butt
2018-05-24 14:47       ` Michal Hocko
2018-05-24 16:37     ` Randy Dunlap
2018-05-25  7:52       ` Michal Hocko
2018-05-28  7:21         ` Nikolay Borisov
2018-05-29  8:22           ` Michal Hocko
2018-05-28 11:32         ` Vlastimil Babka
2018-05-24 20:52     ` Jonathan Corbet
2018-05-24 20:52       ` Jonathan Corbet
2018-05-25  8:11       ` Michal Hocko
2018-05-24 22:17     ` Dave Chinner
2018-05-24 23:25       ` Theodore Y. Ts'o
2018-05-25  8:16       ` Michal Hocko
2018-05-27 12:47         ` Mike Rapoport
2018-05-28  9:21           ` Michal Hocko
2018-05-28 16:10             ` Randy Dunlap
2018-05-29  8:21               ` Michal Hocko
2018-05-27 23:48         ` Dave Chinner
2018-05-28  9:19           ` Michal Hocko
2018-05-28 22:32             ` Dave Chinner
2018-05-29  8:18               ` Michal Hocko
2018-05-29  8:26     ` [PATCH v2] " Michal Hocko
2018-05-29  8:26       ` Michal Hocko
2018-05-29 10:22       ` Dave Chinner
2018-05-29 11:50       ` Mike Rapoport
2018-05-29 11:51       ` Jonathan Corbet
2018-05-29 11:51         ` Jonathan Corbet
2018-05-29 12:37         ` Michal Hocko
2018-07-17 12:49   ` vmalloc with GFP_NOFS Michal Hocko
2018-07-17 12:49     ` [Cluster-devel] " Michal Hocko
2018-07-17 12:49     ` Michal Hocko
2018-04-24 19:03 ` Richard Weinberger
2018-04-24 19:03   ` [Cluster-devel] " Richard Weinberger
2018-04-24 19:03   ` Richard Weinberger
2018-04-24 19:28   ` Michal Hocko
2018-04-24 19:28     ` [Cluster-devel] " Michal Hocko
2018-04-24 19:28     ` Michal Hocko
2018-04-24 22:18     ` Richard Weinberger
2018-04-24 22:18       ` [Cluster-devel] " Richard Weinberger
2018-04-24 22:18       ` Richard Weinberger
2018-04-24 23:09       ` Michal Hocko
2018-04-24 23:09         ` [Cluster-devel] " Michal Hocko
2018-04-24 23:09         ` Michal Hocko
2018-04-24 23:17         ` Mikulas Patocka
2018-04-24 23:17           ` [Cluster-devel] " Mikulas Patocka
2018-04-24 23:17           ` Mikulas Patocka
2018-04-24 23:25           ` Michal Hocko
2018-04-24 23:25             ` [Cluster-devel] " Michal Hocko
2018-04-24 23:25             ` Michal Hocko
2018-04-25 12:43             ` Mikulas Patocka
2018-04-25 12:43               ` [Cluster-devel] " Mikulas Patocka
2018-04-25 12:43               ` Mikulas Patocka
2018-04-25 14:45               ` Michal Hocko
2018-04-25 14:45                 ` [Cluster-devel] " Michal Hocko
2018-04-25 14:45                 ` Michal Hocko
2018-04-25 15:25                 ` Mikulas Patocka [this message]
2018-04-25 15:25                   ` [Cluster-devel] " Mikulas Patocka
2018-04-25 15:25                   ` Mikulas Patocka
2018-04-25 16:56                   ` Michal Hocko
2018-04-25 16:56                     ` [Cluster-devel] " Michal Hocko
2018-04-25 16:56                     ` Michal Hocko
2018-07-17 12:47   ` Michal Hocko
2018-07-17 12:47     ` [Cluster-devel] " Michal Hocko
2018-07-17 12:47     ` Michal Hocko
2018-04-24 19:05 ` Richard Weinberger
2018-04-24 19:05   ` [Cluster-devel] " Richard Weinberger
2018-04-24 19:05   ` Richard Weinberger
2018-04-24 19:10 ` Richard Weinberger
2018-04-24 19:10   ` [Cluster-devel] " Richard Weinberger
2018-04-24 19:10   ` Richard Weinberger
2018-04-24 19:26 ` Steven Whitehouse
2018-04-24 19:26   ` [Cluster-devel] " Steven Whitehouse
2018-04-24 19:26   ` Steven Whitehouse
2018-04-24 20:09   ` Michal Hocko
2018-04-24 20:09     ` [Cluster-devel] " Michal Hocko
2018-04-24 20:09     ` Michal Hocko
2018-07-17 12:50     ` Michal Hocko
2018-07-17 12:50       ` [Cluster-devel] " Michal Hocko
2018-07-17 12:50       ` Michal Hocko

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=alpine.LRH.2.02.1804251114120.11848@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=adrian.hunter@intel.com \
    --cc=anna.schumaker@netapp.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=cluster-devel@redhat.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=mhocko@kernel.org \
    --cc=pombredanne@nexb.com \
    --cc=richard@nod.at \
    --cc=rpeterso@redhat.com \
    --cc=swhiteho@redhat.com \
    --cc=trond.myklebust@primarydata.com \
    --cc=tytso@mit.edu \
    /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.