From: Simon Horman <horms@kernel.org>
To: "Håkon Bugge" <haakon.bugge@oracle.com>
Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, rds-devel@oss.oracle.com,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Tejun Heo <tj@kernel.org>, Lai Jiangshan <jiangshanlai@gmail.com>,
Allison Henderson <allison.henderson@oracle.com>,
Manjunath Patil <manjunath.b.patil@oracle.com>,
Mark Zhang <markzhang@nvidia.com>,
Chuck Lever <chuck.lever@oracle.com>,
Shiraz Saleem <shiraz.saleem@intel.com>,
Yang Li <yang.lee@linux.alibaba.com>
Subject: Re: [PATCH 2/6] rds: Brute force GFP_NOIO
Date: Mon, 13 May 2024 19:14:24 +0100 [thread overview]
Message-ID: <20240513181424.GU2787@kernel.org> (raw)
In-Reply-To: <20240513125346.764076-3-haakon.bugge@oracle.com>
On Mon, May 13, 2024 at 02:53:42PM +0200, Håkon Bugge wrote:
> For most entry points to RDS, we call memalloc_noio_{save,restore} in
> a parenthetic fashion when enabled by the module parameter force_noio.
>
> We skip the calls to memalloc_noio_{save,restore} in rds_ioctl(), as
> no memory allocations are executed in this function or its callees.
>
> The reason we execute memalloc_noio_{save,restore} in rds_poll(), is
> due to the following call chain:
>
> rds_poll()
> poll_wait()
> __pollwait()
> poll_get_entry()
> __get_free_page(GFP_KERNEL)
>
> The function rds_setsockopt() allocates memory in its callee's
> rds_get_mr() and rds_get_mr_for_dest(). Hence, we need
> memalloc_noio_{save,restore} in rds_setsockopt().
>
> In rds_getsockopt(), we have rds_info_getsockopt() that allocates
> memory. Hence, we need memalloc_noio_{save,restore} in
> rds_getsockopt().
>
> All the above, in order to conditionally enable RDS to become a block I/O
> device.
>
> Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
Hi Håkon,
Some minor feedback from my side.
> ---
> net/rds/af_rds.c | 60 +++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 57 insertions(+), 3 deletions(-)
>
> diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
> index 8435a20968ef5..a89d192aabc0b 100644
> --- a/net/rds/af_rds.c
> +++ b/net/rds/af_rds.c
> @@ -37,10 +37,16 @@ > #include <linux/in.h>
> #include <linux/ipv6.h>
> #include <linux/poll.h>
> +#include <linux/sched/mm.h>
> #include <net/sock.h>
>
> #include "rds.h"
>
> +bool rds_force_noio;
> +EXPORT_SYMBOL(rds_force_noio);
rds_force_noio seems to be only used within this file.
I wonder if it should it be static and not EXPORTed?
Flagged by Sparse.
> +module_param_named(force_noio, rds_force_noio, bool, 0444);
> +MODULE_PARM_DESC(force_noio, "Force the use of GFP_NOIO (Y/N)");
> +
> /* this is just used for stats gathering :/ */
> static DEFINE_SPINLOCK(rds_sock_lock);
> static unsigned long rds_sock_count;
> @@ -60,6 +66,10 @@ static int rds_release(struct socket *sock)
> {
> struct sock *sk = sock->sk;
> struct rds_sock *rs;
> + unsigned int noio_flags;
Please consider using reverse xmas tree order - longest line to shortest -
for local variable declarations in Networking code.
This tool can be of assistance: https://github.com/ecree-solarflare/xmastree
> +
> + if (rds_force_noio)
> + noio_flags = memalloc_noio_save();
>
> if (!sk)
> goto out;
...
> @@ -324,6 +346,8 @@ static int rds_cancel_sent_to(struct rds_sock *rs, sockptr_t optval, int len)
>
> rds_send_drop_to(rs, &sin6);
> out:
> + if (rds_force_noio)
> + noio_flags = memalloc_noio_save();
noio_flags appears to be set but otherwise unused in this function.
Flagged by W=1 builds.
> return ret;
> }
>
...
next prev parent reply other threads:[~2024-05-13 18:14 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 12:53 [PATCH 0/6] rds: rdma: Add ability to force GFP_NOIO Håkon Bugge
2024-05-13 12:53 ` [PATCH 1/6] workqueue: Inherit NOIO and NOFS alloc flags Håkon Bugge
2024-05-13 16:48 ` Tejun Heo
2024-05-14 13:48 ` Haakon Bugge
2024-05-14 16:49 ` Tejun Heo
2024-05-15 14:11 ` Haakon Bugge
2024-05-13 12:53 ` [PATCH 2/6] rds: Brute force GFP_NOIO Håkon Bugge
2024-05-13 18:04 ` kernel test robot
2024-05-13 18:14 ` Simon Horman [this message]
2024-05-14 13:31 ` Haakon Bugge
2024-05-13 12:53 ` [PATCH 3/6] RDMA/cma: " Håkon Bugge
2024-05-13 12:53 ` [PATCH 4/6] RDMA/cm: " Håkon Bugge
2024-05-13 12:53 ` [PATCH 5/6] RDMA/mlx5: " Håkon Bugge
2024-05-13 12:53 ` [PATCH 6/6] net/mlx5: " Håkon Bugge
2024-05-13 23:03 ` [PATCH 0/6] rds: rdma: Add ability to " Jason Gunthorpe
2024-05-14 18:19 ` Haakon Bugge
2024-05-17 17:30 ` Jason Gunthorpe
2024-05-14 8:53 ` Zhu Yanjun
2024-05-14 12:02 ` Zhu Yanjun
2024-05-14 18:32 ` Haakon Bugge
2024-05-15 10:25 ` Zhu Yanjun
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=20240513181424.GU2787@kernel.org \
--to=horms@kernel.org \
--cc=allison.henderson@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=haakon.bugge@oracle.com \
--cc=jgg@ziepe.ca \
--cc=jiangshanlai@gmail.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=manjunath.b.patil@oracle.com \
--cc=markzhang@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rds-devel@oss.oracle.com \
--cc=saeedm@nvidia.com \
--cc=shiraz.saleem@intel.com \
--cc=tariqt@nvidia.com \
--cc=tj@kernel.org \
--cc=yang.lee@linux.alibaba.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.