All of lore.kernel.org
 help / color / mirror / Atom feed
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)

  reply	other threads:[~2017-11-01 15:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31 23:33 [PATCH] dm: allocate struct mapped_device with kvzalloc Mikulas Patocka
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 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.