From: Bart Van Assche <bvanassche@acm.org>
To: Ming Lei <ming.lei@redhat.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-scsi@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
"Ewan D . Milne" <emilne@redhat.com>,
Hannes Reinecke <hare@suse.com>
Subject: Re: [PATCH V4 2/3] scsi: core: avoid to pre-allocate big chunk for protection meta data
Date: Mon, 29 Apr 2019 11:15:52 -0700 [thread overview]
Message-ID: <1556561752.161891.165.camel@acm.org> (raw)
In-Reply-To: <20190428073932.9898-3-ming.lei@redhat.com>
On Sun, 2019-04-28 at 15:39 +0800, Ming Lei wrote:
> Now scsi_mq_setup_tags() pre-allocates a big buffer for protection
> sg entries, and the buffer size is scsi_mq_sgl_size().
>
> This way isn't correct, scsi_mq_sgl_size() is used to pre-allocate
> sg entries for IO data. And the protection data buffer is much less,
> for example, one 512byte sector needs 8byte protection data, and
> the max sector number for one request is 2560(BLK_DEF_MAX_SECTORS),
> so the max protection data size is just 20k.
>
> The usual case is that one bio builds one single bip segment. Attribute
> to bio split, bio merge is seldom done for big IO, and it is only done
> in case of small bios. And protection data segment number is usually
> same with bio count in the request, so the number won't be very big,
> and allocating from slab is fast enough.
>
> Reduce to pre-allocate one sg entry for protection data, and switch
> to runtime allocation in case that the protection data segment number
> is bigger than 1. Then we can save huge pre-alocation, for example,
> 500
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
next prev parent reply other threads:[~2019-04-29 18:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-28 7:39 [PATCH V4 0/3] scsi: core: avoid big pre-allocation for sg list Ming Lei
2019-04-28 7:39 ` Ming Lei
2019-04-28 7:39 ` [PATCH V4 1/3] lib/sg_pool.c: improve APIs for allocating sg pool Ming Lei
2019-04-28 7:39 ` Ming Lei
2019-04-28 12:04 ` Christoph Hellwig
2019-04-28 12:04 ` Christoph Hellwig
2019-04-28 7:39 ` [PATCH V4 2/3] scsi: core: avoid to pre-allocate big chunk for protection meta data Ming Lei
2019-04-29 18:15 ` Bart Van Assche [this message]
2019-04-28 7:39 ` [PATCH V4 3/3] scsi: core: avoid to pre-allocate big chunk for sg list Ming Lei
2019-04-29 18:16 ` Bart Van Assche
2019-06-03 20:44 ` Guenter Roeck
2019-06-04 1:00 ` Ming Lei
2019-06-04 3:49 ` Guenter Roeck
2019-06-04 4:10 ` Ming Lei
2019-06-04 14:51 ` Guenter Roeck
2019-06-04 6:55 ` Ming Lei
2019-05-05 1:10 ` [PATCH V4 0/3] scsi: core: avoid big pre-allocation " Ming Lei
2019-05-05 1:10 ` Ming Lei
2019-05-14 2:06 ` Martin K. Petersen
2019-05-14 2:06 ` Martin K. Petersen
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=1556561752.161891.165.camel@acm.org \
--to=bvanassche@acm.org \
--cc=James.Bottomley@HansenPartnership.com \
--cc=emilne@redhat.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@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.