From: Mike Snitzer <snitzer@redhat.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Zdenek Kabelac <zkabelac@redhat.com>,
"Alasdair G. Kergon" <agk@redhat.com>,
dm-devel@redhat.com,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: SRCU's apparent use of NR_CPUS? [was: re: dm: allocate struct mapped_device with kvzalloc]
Date: Wed, 1 Nov 2017 11:48:44 -0400 [thread overview]
Message-ID: <20171101154844.GA25792@redhat.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1710311931190.28120@file01.intranet.prod.int.rdu2.redhat.com>
[cc'ing Paul, and LKML, to get his/others' take on SRCU cpu scaling]
On Tue, Oct 31 2017 at 7:33pm -0400,
Mikulas Patocka <mpatocka@redhat.com> wrote:
> The structure srcu_struct can be very big, its size is proportional to the
> value CONFIG_NR_CPUS. The Fedora kernel has CONFIG_NR_CPUS 8192, the field
> io_barrier in the struct mapped_device has 84kB in the debugging kernel
> and 50kB in the non-debugging kernel. The large size may result in failure
> of the function kzalloc_node.
>
> In order to avoid the allocation failure, we use the function
> kvzalloc_node, this function falls back to vmalloc if a large contiguous
> chunk of memory is not available. This patch also moves the field
> io_barrier to the last position of struct mapped_device - the reason is
> that on many processor architectures, short memory offsets result in
> smaller code than long memory offsets - on x86-64 it reduces code size by
> 320 bytes.
>
> Note to stable kernel maintainers - the kernels 4.11 and older don't have
> the function kvzalloc_node, you can use the function vzalloc_node instead.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Cc: stable@vger.kernel.org
This looks reasonable as a near-term workaround.. BUT:
Paul has there been any discussion about how to make SRCU support
dynamically scaling up to NR_CPUS maximum as 'nr_cpus' changes (rather
than accounting for worst case of NR_CPUS up-front)?
(But I had a quick look at scrutree.h and I'm not seeing explicit use of
NR_CPUS, so it is likely occuring via implicit percpu through some
member of 'struct srcu_struct', e.g. 'sda'?)
Thanks,
Mike
>
> ---
> drivers/md/dm-core.h | 3 ++-
> drivers/md/dm.c | 6 +++---
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> Index: linux-2.6/drivers/md/dm-core.h
> ===================================================================
> --- linux-2.6.orig/drivers/md/dm-core.h
> +++ linux-2.6/drivers/md/dm-core.h
> @@ -29,7 +29,6 @@ struct dm_kobject_holder {
> * DM targets must _not_ deference a mapped_device to directly access its members!
> */
> struct mapped_device {
> - struct srcu_struct io_barrier;
> struct mutex suspend_lock;
>
> /*
> @@ -127,6 +126,8 @@ struct mapped_device {
> struct blk_mq_tag_set *tag_set;
> bool use_blk_mq:1;
> bool init_tio_pdu:1;
> +
> + struct srcu_struct io_barrier;
> };
>
> void dm_init_md_queue(struct mapped_device *md);
> Index: linux-2.6/drivers/md/dm.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/dm.c
> +++ linux-2.6/drivers/md/dm.c
> @@ -1695,7 +1695,7 @@ static struct mapped_device *alloc_dev(i
> struct mapped_device *md;
> void *old_md;
>
> - md = kzalloc_node(sizeof(*md), GFP_KERNEL, numa_node_id);
> + md = kvzalloc_node(sizeof(*md), GFP_KERNEL, numa_node_id);
> if (!md) {
> DMWARN("unable to allocate device, out of memory.");
> return NULL;
> @@ -1795,7 +1795,7 @@ bad_io_barrier:
> bad_minor:
> module_put(THIS_MODULE);
> bad_module_get:
> - kfree(md);
> + kvfree(md);
> return NULL;
> }
>
> @@ -1814,7 +1814,7 @@ static void free_dev(struct mapped_devic
> free_minor(minor);
>
> module_put(THIS_MODULE);
> - kfree(md);
> + kvfree(md);
> }
>
> static void __bind_mempools(struct mapped_device *md, struct dm_table *t)
next parent reply other threads:[~2017-11-01 15:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.LRH.2.02.1710311931190.28120@file01.intranet.prod.int.rdu2.redhat.com>
2017-11-01 15:48 ` Mike Snitzer [this message]
2017-11-01 16:23 ` SRCU's apparent use of NR_CPUS? [was: re: dm: allocate struct mapped_device with kvzalloc] Paul E. McKenney
2017-11-01 21:32 ` Mike Snitzer
2017-11-03 20:10 ` Mikulas Patocka
2018-01-12 19:18 ` Paul E. McKenney
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=20171101154844.GA25792@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=zkabelac@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox