From: Bart Van Assche <bvanassche@acm.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Ming Lei <ming.lei@redhat.com>
Cc: linux-scsi@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>,
linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
"Ewan D . Milne" <emilne@redhat.com>,
Hannes Reinecke <hare@suse.com>
Subject: Re: [PATCH 2/2] scsi: core: avoid to pre-allocate big chunk for sg list
Date: Wed, 24 Apr 2019 09:09:42 -0700 [thread overview]
Message-ID: <1556122182.161891.135.camel@acm.org> (raw)
In-Reply-To: <1556120991.3043.20.camel@HansenPartnership.com>
On Wed, 2019-04-24 at 08:49 -0700, James Bottomley wrote:
> On Wed, 2019-04-24 at 08:32 -0700, Bart Van Assche wrote:
> > Another concern is whether this change can cause a livelock. If the
> > system is running out of memory and the page cache submits a write
> > request with a scatterlist with more than two elements, if the
> > kmalloc() for the scatterlist fails, will that prevent the page cache
> > from making any progress with writeback?
>
> It's pool backed, as I said. Is the concern there isn't enough depth
> in the pools for a large write?
That memory pool is used by multiple drivers. Most but not all
sg_alloc_table_chained() calls happen from inside .queue_rq() implementations.
One sg_alloc_table_chained() call occurs in the NFS server code. I'm not sure
whether it is guaranteed that an sg_alloc_table_chained() will succeed sooner
or later under low memory conditions. Additionally, new
sg_alloc_table_chained() could be added in drivers any time.
Bart.
next prev parent reply other threads:[~2019-04-24 16:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-23 10:32 [PATCH 0/2] scis: core: avoid big pre-allocation for sg list Ming Lei
2019-04-23 10:32 ` [PATCH 1/2] scsi: core: avoid to pre-allocate big chunk for protection meta data Ming Lei
2019-04-23 15:33 ` Bart Van Assche
2019-04-24 0:46 ` Ming Lei
2019-04-23 10:32 ` [PATCH 2/2] scsi: core: avoid to pre-allocate big chunk for sg list Ming Lei
2019-04-23 15:37 ` Bart Van Assche
2019-04-24 7:52 ` Ming Lei
2019-04-24 15:24 ` James Bottomley
2019-04-24 15:32 ` Bart Van Assche
2019-04-24 15:37 ` Jens Axboe
2019-04-24 15:49 ` James Bottomley
2019-04-24 16:09 ` Bart Van Assche [this message]
2019-04-24 16:17 ` James Bottomley
2019-04-24 5:53 ` Christoph Hellwig
2019-04-24 8:41 ` Ming Lei
2019-04-24 14:38 ` Christoph Hellwig
2019-04-25 0:45 ` Ming Lei
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=1556122182.161891.135.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.