All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Sagi Grimberg <sagi@grimberg.me>, Ming Lei <ming.lei@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>, Hannes Reinecke <hare@suse.com>,
	Bart van Assche <bvanassche@acm.org>,
	Ming Lei <ming.lei@gmail.com>,
	neilb@suse.com, linux-nvme@lists.infradead.org,
	linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] block: use static bio_set for bio_split() calls
Date: Wed, 24 Apr 2019 20:56:05 +0200	[thread overview]
Message-ID: <69845bdb-cfc6-58d4-4fea-b06c2dd44872@suse.de> (raw)
In-Reply-To: <98d8549a-2663-b404-e38a-6f55dfb575bf@grimberg.me>

On 4/24/19 7:20 PM, Sagi Grimberg wrote:
> 
>> per-queue bioset is used originally for avoiding deadlock, are you
>> sure the static bioset is safe?
> 
> Can you explain this? I didn't find any indication of that in the change
> log history...
> 
> Originally introduced by Kent:
> -- 
> commit 54efd50bfd873e2dbf784e0b21a8027ba4299a3e
> Author: Kent Overstreet <kent.overstreet@gmail.com>
> Date:   Thu Apr 23 22:37:18 2015 -0700
> 
Phew. I was wondering whether I'd been too stupid to find it.
And having looked at it a bit closer, moving the bioset into the holding 
structure would induce more churn, as we'd need to pass the bioset into
blk_queue_split(), which would mean to update all drivers (11 in total) 
for no real gain IMO; bio splitting shouldn't really be a regular 
occurrence and hence the bioset should only be used infrequently.

However, I really would like to get feedback to the actual patch, as 
this solves a real customer issues we've had (or still have, depending 
on the view :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@suse.de                              +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

WARNING: multiple messages have this Message-ID (diff)
From: hare@suse.de (Hannes Reinecke)
Subject: [PATCH] block: use static bio_set for bio_split() calls
Date: Wed, 24 Apr 2019 20:56:05 +0200	[thread overview]
Message-ID: <69845bdb-cfc6-58d4-4fea-b06c2dd44872@suse.de> (raw)
In-Reply-To: <98d8549a-2663-b404-e38a-6f55dfb575bf@grimberg.me>

On 4/24/19 7:20 PM, Sagi Grimberg wrote:
> 
>> per-queue bioset is used originally for avoiding deadlock, are you
>> sure the static bioset is safe?
> 
> Can you explain this? I didn't find any indication of that in the change
> log history...
> 
> Originally introduced by Kent:
> -- 
> commit 54efd50bfd873e2dbf784e0b21a8027ba4299a3e
> Author: Kent Overstreet <kent.overstreet at gmail.com>
> Date:?? Thu Apr 23 22:37:18 2015 -0700
> 
Phew. I was wondering whether I'd been too stupid to find it.
And having looked at it a bit closer, moving the bioset into the holding 
structure would induce more churn, as we'd need to pass the bioset into
blk_queue_split(), which would mean to update all drivers (11 in total) 
for no real gain IMO; bio splitting shouldn't really be a regular 
occurrence and hence the bioset should only be used infrequently.

However, I really would like to get feedback to the actual patch, as 
this solves a real customer issues we've had (or still have, depending 
on the view :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare at suse.de                              +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg
GF: Felix Imend?rffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG N?rnberg)

  reply	other threads:[~2019-04-24 18:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-18 14:06 [PATCH] block: use static bio_set for bio_split() calls Hannes Reinecke
2019-04-18 14:06 ` Hannes Reinecke
2019-04-18 14:34 ` Ming Lei
2019-04-18 14:34   ` Ming Lei
2019-04-18 15:02   ` Hannes Reinecke
2019-04-18 15:02     ` Hannes Reinecke
2019-04-18 18:26     ` Edmund Nadolski (Microsoft)
2019-04-18 18:26       ` Edmund Nadolski (Microsoft)
2019-04-24 17:20   ` Sagi Grimberg
2019-04-24 17:20     ` Sagi Grimberg
2019-04-24 18:56     ` Hannes Reinecke [this message]
2019-04-24 18:56       ` Hannes Reinecke
2019-04-24 18:58       ` Sagi Grimberg
2019-04-24 18:58         ` Sagi Grimberg
2019-04-24 22:14     ` Ming Lei
2019-04-24 22:14       ` Ming Lei
2019-04-25  0:41       ` Ming Lei
2019-04-25  0:41         ` Ming Lei
2019-04-25 14:32         ` Hannes Reinecke
2019-04-25 14:32           ` Hannes Reinecke
2019-04-25 15:36           ` Ming Lei
2019-04-25 15:36             ` Ming Lei
2019-04-30 11:48             ` Hannes Reinecke
2019-04-30 11:48               ` Hannes Reinecke
2019-04-24 19:49 ` Bart Van Assche
2019-04-24 19:49   ` Bart Van Assche
2019-04-25  6:06   ` Hannes Reinecke
2019-04-25  6:06     ` Hannes Reinecke

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=69845bdb-cfc6-58d4-4fea-b06c2dd44872@suse.de \
    --to=hare@suse.de \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=ming.lei@gmail.com \
    --cc=ming.lei@redhat.com \
    --cc=neilb@suse.com \
    --cc=sagi@grimberg.me \
    /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.