Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells
On 07/07/2017 07:51 PM, Goldwyn Rodrigues wrote: > > > On 07/04/2017 05:16 PM, Jens Axboe wrote: >> >> Please expedite getting this upstream, asap. >> > > Jens, > > I have posted an updated patch [1] and it is acked by David. Would you > pick it up or should it go through the btrfs tree (or some other tree)? > > [1] https://patchwork.kernel.org/patch/9825813/ I'm fine with either, I just want it to go in asap. I'm sending off a pull Monday. David, up to you. -- Jens Axboe
Re: Commit edf064e7c (btrfs: nowait aio support) breaks shells
On 07/04/2017 05:16 PM, Jens Axboe wrote: > > Please expedite getting this upstream, asap. > Jens, I have posted an updated patch [1] and it is acked by David. Would you pick it up or should it go through the btrfs tree (or some other tree)? [1] https://patchwork.kernel.org/patch/9825813/ -- Goldwyn
Re: [PATCH 4/4] block_dev: support RFW_NOWAIT on block device nodes
Hi Christoph,
[auto build test WARNING on linus/master]
[also build test WARNING on next-20170707]
[cannot apply to v4.12]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christoph-Hellwig/fs-pass-iocb-to-do_generic_file_read/20170708-020747
config: x86_64-randconfig-x012-201727 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
In file included from include/linux/init.h:4:0,
from fs/block_dev.c:8:
fs/block_dev.c: In function 'blkdev_write_iter':
fs/block_dev.c:1895:21: warning: suggest parentheses around comparison in
operand of '&' [-Wparentheses]
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
^
include/linux/compiler.h:156:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> fs/block_dev.c:1895:2: note: in expansion of macro 'if'
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
^~
fs/block_dev.c:1895:21: warning: suggest parentheses around comparison in
operand of '&' [-Wparentheses]
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
^
include/linux/compiler.h:156:42: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> fs/block_dev.c:1895:2: note: in expansion of macro 'if'
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
^~
fs/block_dev.c:1895:21: warning: suggest parentheses around comparison in
operand of '&' [-Wparentheses]
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
^
include/linux/compiler.h:167:16: note: in definition of macro '__trace_if'
__r = !!(cond); \
^~~~
>> fs/block_dev.c:1895:2: note: in expansion of macro 'if'
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
^~
vim +/if +1895 fs/block_dev.c
1879 {
1880 struct file *file = iocb->ki_filp;
1881 struct inode *bd_inode = bdev_file_inode(file);
1882 loff_t size = i_size_read(bd_inode);
1883 struct blk_plug plug;
1884 ssize_t ret;
1885
1886 if (bdev_read_only(I_BDEV(bd_inode)))
1887 return -EPERM;
1888
1889 if (!iov_iter_count(from))
1890 return 0;
1891
1892 if (iocb->ki_pos >= size)
1893 return -ENOSPC;
1894
> 1895 if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
1896 return -EOPNOTSUPP;
1897
1898 iov_iter_truncate(from, size - iocb->ki_pos);
1899
1900 blk_start_plug(&plug);
1901 ret = __generic_file_write_iter(iocb, from);
1902 if (ret > 0)
1903 ret = generic_write_sync(iocb, ret);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 4/4] block_dev: support RFW_NOWAIT on block device nodes
Hi Christoph,
[auto build test WARNING on linus/master]
[also build test WARNING on next-20170707]
[cannot apply to v4.12]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christoph-Hellwig/fs-pass-iocb-to-do_generic_file_read/20170708-020747
config: x86_64-randconfig-x015-201727 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
fs/block_dev.c: In function 'blkdev_write_iter':
>> fs/block_dev.c:1895:21: warning: suggest parentheses around comparison in
>> operand of '&' [-Wparentheses]
if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
^
vim +1895 fs/block_dev.c
1879 {
1880 struct file *file = iocb->ki_filp;
1881 struct inode *bd_inode = bdev_file_inode(file);
1882 loff_t size = i_size_read(bd_inode);
1883 struct blk_plug plug;
1884 ssize_t ret;
1885
1886 if (bdev_read_only(I_BDEV(bd_inode)))
1887 return -EPERM;
1888
1889 if (!iov_iter_count(from))
1890 return 0;
1891
1892 if (iocb->ki_pos >= size)
1893 return -ENOSPC;
1894
> 1895 if (iocb->ki_flags & (IOCB_NOWAIT | IOCB_DIRECT) == IOCB_NOWAIT)
1896 return -EOPNOTSUPP;
1897
1898 iov_iter_truncate(from, size - iocb->ki_pos);
1899
1900 blk_start_plug(&plug);
1901 ret = __generic_file_write_iter(iocb, from);
1902 if (ret > 0)
1903 ret = generic_write_sync(iocb, ret);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 0/2] LightNVM: Fixes for 4.13
On 07/07/2017 01:08 PM, Javier González wrote: > Hi Jens, > > I have 2 extra fixes for this window. One is for controlling write I/Os > when removing a pblk partition, otherwise, some controllers can be > overflowed. We do the same on the fast write path. > > This should be the last fixes coming from our side. Added for 4.13, thanks. -- Jens Axboe
RE: device support in hpasa, was: Re: OOPS from cciss_ioctl in 4.12+git
> -Original Message- > From: Hannes Reinecke [mailto:h...@suse.de] > Sent: Friday, July 07, 2017 11:05 AM > To: Jens Axboe ; Christoph Hellwig > ; Meelis Roos > Cc: Linux Kernel list ; linux- > bl...@vger.kernel.org; Don Brace ; Scott > Benesh ; Scott Teel > ; Kevin Barnett > ; linux-s...@vger.kernel.org > Subject: Re: device support in hpasa, was: Re: OOPS from cciss_ioctl in > 4.12+git > > EXTERNAL EMAIL > > > On 07/07/2017 05:03 PM, Jens Axboe wrote: > > On 07/07/2017 09:00 AM, Christoph Hellwig wrote: > >> On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote: > Also we're trying to move people away from the cciss driver, can you > check if the hpsa SCSI driver works for you as well? > >>> > >>> I have older adapter: > >>> > >>> Compaq Computer Corporation Smart Array 64xx [0e11:0046] (rev 01) > >>> > >>> That does not seem to be supported by hpsa AFAICS. > >> > >> Looks like. Although hpsa has support for various SA5 controllers > >> it seems like it decided to skip all Compaq branded controllers. > >> > >> As far as I can tell we could simply add support for those to > >> hpsa. Ccing hpsa folks to figure out if that's the case. > > > > Pretty sure Hannes had a patch he tested for that, he talked about > > that back at LSFMM earlier this year. Hannes? > > > Oh, I do. > hpsa is working happily on SLES for _all_ SmartArray controllers. > You need to enable 'hpsa_allow_any=1', though. > But I'm perfectly happy with making that the default and drop cciss > completely. > > Cheers, > > Hannes > -- > Dr. Hannes ReineckeTeamlead Storage & Networking > h...@suse.de +49 911 74053 688 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG Nürnberg) The 6400 controllers are quite old and are no longer tested. So, it would be nice to deprecate the cciss driver, but we would not support those formerly cciss devices with hpsa. I do not recall seeing a cciss_ioctl issue, what was the issue? Thanks, Don Brace ESC - Smart Storage Microsemi Corporation
[PATCH 0/2] LightNVM: Fixes for 4.13
Hi Jens, I have 2 extra fixes for this window. One is for controlling write I/Os when removing a pblk partition, otherwise, some controllers can be overflowed. We do the same on the fast write path. This should be the last fixes coming from our side. They apply on top of your for-4.13/block and can be found at: https://github.com/OpenChannelSSD/linux pblk.for-4.13 Thanks, Javier Javier González (2): lightnvm: pblk: control I/O flow also on tear down lightnvm: pblk: remove unnecessary checks drivers/lightnvm/pblk-core.c | 69 ++-- drivers/lightnvm/pblk-recovery.c | 31 -- drivers/lightnvm/pblk-write.c| 26 +-- drivers/lightnvm/pblk.h | 2 ++ 4 files changed, 83 insertions(+), 45 deletions(-) -- 2.7.4
[PATCH 2/2] lightnvm: pblk: remove unnecessary checks
Remove unnecessary checks when freeing dma memory in the completion path. Signed-off-by: Javier González Signed-off-by: Matias Bjørling --- drivers/lightnvm/pblk-write.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/lightnvm/pblk-write.c b/drivers/lightnvm/pblk-write.c index cc2b9414d17c..3ad9e56d2473 100644 --- a/drivers/lightnvm/pblk-write.c +++ b/drivers/lightnvm/pblk-write.c @@ -39,9 +39,7 @@ static unsigned long pblk_end_w_bio(struct pblk *pblk, struct nvm_rq *rqd, ret = pblk_rb_sync_advance(&pblk->rwb, c_ctx->nr_valid); - if (rqd->meta_list) - nvm_dev_dma_free(dev->parent, rqd->meta_list, - rqd->dma_meta_list); + nvm_dev_dma_free(dev->parent, rqd->meta_list, rqd->dma_meta_list); bio_put(rqd->bio); pblk_free_rqd(pblk, rqd, WRITE); @@ -224,9 +222,6 @@ static int pblk_alloc_w_rq(struct pblk *pblk, struct nvm_rq *rqd, if (!rqd->meta_list) return -ENOMEM; - if (unlikely(nr_secs == 1)) - return 0; - rqd->ppa_list = rqd->meta_list + pblk_dma_meta_size; rqd->dma_ppa_list = rqd->dma_meta_list + pblk_dma_meta_size; -- 2.7.4
[PATCH 1/2] lightnvm: pblk: control I/O flow also on tear down
When removing a pblk instance, control the write I/O flow to the
controller as we do in the fast path.
Signed-off-by: Javier González
Signed-off-by: Matias Bjørling
---
drivers/lightnvm/pblk-core.c | 69 ++--
drivers/lightnvm/pblk-recovery.c | 31 --
drivers/lightnvm/pblk-write.c| 19 ---
drivers/lightnvm/pblk.h | 2 ++
4 files changed, 82 insertions(+), 39 deletions(-)
diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c
index 11fe0c5b2a9c..81501644fb15 100644
--- a/drivers/lightnvm/pblk-core.c
+++ b/drivers/lightnvm/pblk-core.c
@@ -1670,13 +1670,10 @@ void pblk_line_run_ws(struct pblk *pblk, struct
pblk_line *line, void *priv,
queue_work(wq, &line_ws->ws);
}
-void pblk_down_rq(struct pblk *pblk, struct ppa_addr *ppa_list, int nr_ppas,
- unsigned long *lun_bitmap)
+static void __pblk_down_page(struct pblk *pblk, struct ppa_addr *ppa_list,
+int nr_ppas, int pos)
{
- struct nvm_tgt_dev *dev = pblk->dev;
- struct nvm_geo *geo = &dev->geo;
- struct pblk_lun *rlun;
- int pos = pblk_ppa_to_pos(geo, ppa_list[0]);
+ struct pblk_lun *rlun = &pblk->luns[pos];
int ret;
/*
@@ -1690,24 +1687,62 @@ void pblk_down_rq(struct pblk *pblk, struct ppa_addr
*ppa_list, int nr_ppas,
WARN_ON(ppa_list[0].g.lun != ppa_list[i].g.lun ||
ppa_list[0].g.ch != ppa_list[i].g.ch);
#endif
+
+ ret = down_timeout(&rlun->wr_sem, msecs_to_jiffies(3));
+ if (ret) {
+ switch (ret) {
+ case -ETIME:
+ pr_err("pblk: lun semaphore timed out\n");
+ break;
+ case -EINTR:
+ pr_err("pblk: lun semaphore timed out\n");
+ break;
+ }
+ }
+}
+
+void pblk_down_page(struct pblk *pblk, struct ppa_addr *ppa_list, int nr_ppas)
+{
+ struct nvm_tgt_dev *dev = pblk->dev;
+ struct nvm_geo *geo = &dev->geo;
+ int pos = pblk_ppa_to_pos(geo, ppa_list[0]);
+
+ __pblk_down_page(pblk, ppa_list, nr_ppas, pos);
+}
+
+void pblk_down_rq(struct pblk *pblk, struct ppa_addr *ppa_list, int nr_ppas,
+ unsigned long *lun_bitmap)
+{
+ struct nvm_tgt_dev *dev = pblk->dev;
+ struct nvm_geo *geo = &dev->geo;
+ int pos = pblk_ppa_to_pos(geo, ppa_list[0]);
+
/* If the LUN has been locked for this same request, do no attempt to
* lock it again
*/
if (test_and_set_bit(pos, lun_bitmap))
return;
+ __pblk_down_page(pblk, ppa_list, nr_ppas, pos);
+}
+
+void pblk_up_page(struct pblk *pblk, struct ppa_addr *ppa_list, int nr_ppas)
+{
+ struct nvm_tgt_dev *dev = pblk->dev;
+ struct nvm_geo *geo = &dev->geo;
+ struct pblk_lun *rlun;
+ int pos = pblk_ppa_to_pos(geo, ppa_list[0]);
+
+#ifdef CONFIG_NVM_DEBUG
+ int i;
+
+ for (i = 1; i < nr_ppas; i++)
+ WARN_ON(ppa_list[0].g.lun != ppa_list[i].g.lun ||
+ ppa_list[0].g.ch != ppa_list[i].g.ch);
+#endif
+
rlun = &pblk->luns[pos];
- ret = down_timeout(&rlun->wr_sem, msecs_to_jiffies(5000));
- if (ret) {
- switch (ret) {
- case -ETIME:
- pr_err("pblk: lun semaphore timed out\n");
- break;
- case -EINTR:
- pr_err("pblk: lun semaphore timed out\n");
- break;
- }
- }
+ up(&rlun->wr_sem);
}
void pblk_up_rq(struct pblk *pblk, struct ppa_addr *ppa_list, int nr_ppas,
diff --git a/drivers/lightnvm/pblk-recovery.c b/drivers/lightnvm/pblk-recovery.c
index 0e48d3e4e143..cb556e06673e 100644
--- a/drivers/lightnvm/pblk-recovery.c
+++ b/drivers/lightnvm/pblk-recovery.c
@@ -340,9 +340,14 @@ static void pblk_end_io_recov(struct nvm_rq *rqd)
struct pblk *pblk = pad_rq->pblk;
struct nvm_tgt_dev *dev = pblk->dev;
- kref_put(&pad_rq->ref, pblk_recov_complete);
+ pblk_up_page(pblk, rqd->ppa_list, rqd->nr_ppas);
+
+ bio_put(rqd->bio);
nvm_dev_dma_free(dev->parent, rqd->meta_list, rqd->dma_meta_list);
pblk_free_rqd(pblk, rqd, WRITE);
+
+ atomic_dec(&pblk->inflight_io);
+ kref_put(&pad_rq->ref, pblk_recov_complete);
}
static int pblk_recov_pad_oob(struct pblk *pblk, struct pblk_line *line,
@@ -385,7 +390,7 @@ static int pblk_recov_pad_oob(struct pblk *pblk, struct
pblk_line *line,
rq_ppas = pblk_calc_secs(pblk, left_ppas, 0);
if (rq_ppas < pblk->min_write_pgs) {
pr_err("pblk: corrupted pad line %d\n", line->id);
- goto free_rq;
+ goto fail_free_pad;
}
rq_len = rq_ppas * geo->sec_size;
@@ -393,7 +398,7 @@ static int pblk_recov_pad_oob(struct pblk *pblk,
Re: device support in hpsa, was: Re: OOPS from cciss_ioctl in 4.12+git
On 07/07/2017 02:08 PM, Christoph Hellwig wrote: On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote: What happens when hpsa_allow_any=1 with the Smart Array 64xx It should probe. But only if it has a HP vendor ID as far as I can tell. We'd still need to add the compaq ids so that these controllers get probed. But maybe it's time to add them and flip the hpsa_allow_any default (maybe conditionally on a config option?) and mark cciss deprecated. Agreed, I vote yes.
Re: device support in hpsa, was: Re: OOPS from cciss_ioctl in 4.12+git
On Fri, Jul 07, 2017 at 11:42:38AM -0400, Laurence Oberman wrote: > What happens when hpsa_allow_any=1 with the Smart Array 64xx > It should probe. But only if it has a HP vendor ID as far as I can tell. We'd still need to add the compaq ids so that these controllers get probed. But maybe it's time to add them and flip the hpsa_allow_any default (maybe conditionally on a config option?) and mark cciss deprecated.
Re: [PATCH v2] btrfs: Correct assignment of pos
On Tue, Jul 04, 2017 at 10:33:07PM -0500, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Assigning pos for usage early messes up in append mode, where
> the pos is re-assigned in generic_write_checks(). Assign
> pos later to get the correct position to write from iocb->ki_pos.
>
> Since check_can_nocow also uses the value of pos, we shift
> generic_write_checks() before check_can_nocow(). Checks with
> IOCB_DIRECT are present in generic_write_checks(), so checking
> for IOCB_NOWAIT is enough.
>
> Also, put locking sequence in the fast path.
>
> Changes since v1:
> - Moved pos higher up to encompass check_can_nocow() call.
>
> Fixes: edf064e7c6fe ("btrfs: nowait aio support")
> Signed-off-by: Goldwyn Rodrigues
Acked-by: David Sterba
Re: device support in hpasa, was: Re: OOPS from cciss_ioctl in 4.12+git
On 07/07/2017 05:03 PM, Jens Axboe wrote: > On 07/07/2017 09:00 AM, Christoph Hellwig wrote: >> On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote: Also we're trying to move people away from the cciss driver, can you check if the hpsa SCSI driver works for you as well? >>> >>> I have older adapter: >>> >>> Compaq Computer Corporation Smart Array 64xx [0e11:0046] (rev 01) >>> >>> That does not seem to be supported by hpsa AFAICS. >> >> Looks like. Although hpsa has support for various SA5 controllers >> it seems like it decided to skip all Compaq branded controllers. >> >> As far as I can tell we could simply add support for those to >> hpsa. Ccing hpsa folks to figure out if that's the case. > > Pretty sure Hannes had a patch he tested for that, he talked about > that back at LSFMM earlier this year. Hannes? > Oh, I do. hpsa is working happily on SLES for _all_ SmartArray controllers. You need to enable 'hpsa_allow_any=1', though. But I'm perfectly happy with making that the default and drop cciss completely. Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
Re: device support in hpasa, was: Re: OOPS from cciss_ioctl in 4.12+git
On 07/07/2017 11:03 AM, Jens Axboe wrote: On 07/07/2017 09:00 AM, Christoph Hellwig wrote: On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote: Also we're trying to move people away from the cciss driver, can you check if the hpsa SCSI driver works for you as well? I have older adapter: Compaq Computer Corporation Smart Array 64xx [0e11:0046] (rev 01) That does not seem to be supported by hpsa AFAICS. Looks like. Although hpsa has support for various SA5 controllers it seems like it decided to skip all Compaq branded controllers. As far as I can tell we could simply add support for those to hpsa. Ccing hpsa folks to figure out if that's the case. Pretty sure Hannes had a patch he tested for that, he talked about that back at LSFMM earlier this year. Hannes? What happens when hpsa_allow_any=1 with the Smart Array 64xx It should probe.
Re: device support in hpasa, was: Re: OOPS from cciss_ioctl in 4.12+git
On 07/07/2017 09:00 AM, Christoph Hellwig wrote: > On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote: >>> Also we're trying to move people away from the cciss driver, can you >>> check if the hpsa SCSI driver works for you as well? >> >> I have older adapter: >> >> Compaq Computer Corporation Smart Array 64xx [0e11:0046] (rev 01) >> >> That does not seem to be supported by hpsa AFAICS. > > Looks like. Although hpsa has support for various SA5 controllers > it seems like it decided to skip all Compaq branded controllers. > > As far as I can tell we could simply add support for those to > hpsa. Ccing hpsa folks to figure out if that's the case. Pretty sure Hannes had a patch he tested for that, he talked about that back at LSFMM earlier this year. Hannes? -- Jens Axboe
device support in hpasa, was: Re: OOPS from cciss_ioctl in 4.12+git
On Thu, Jul 06, 2017 at 12:55:04PM +0300, Meelis Roos wrote: > > Also we're trying to move people away from the cciss driver, can you > > check if the hpsa SCSI driver works for you as well? > > I have older adapter: > > Compaq Computer Corporation Smart Array 64xx [0e11:0046] (rev 01) > > That does not seem to be supported by hpsa AFAICS. Looks like. Although hpsa has support for various SA5 controllers it seems like it decided to skip all Compaq branded controllers. As far as I can tell we could simply add support for those to hpsa. Ccing hpsa folks to figure out if that's the case.
Re: [PATCH 2/4] fs: support IOCB_NOWAIT in generic_file_buffered_read
On Thu, Jul 06, 2017 at 08:30:17AM -0700, Christoph Hellwig wrote:
> From: Milosz Tanski
>
> Allow generic_file_buffered_read to bail out early instead of waiting for
> the page lock or reading a page if IOCB_NOWAIT is specified.
>
> Signed-off-by: Milosz Tanski
> Reviewed-by: Christoph Hellwig
> Reviewed-by: Jeff Moyer
> Acked-by: Sage Weil
Acked-by: Mel Gorman
> ---
> mm/filemap.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 9865350d6b89..bb70b64ffb48 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1843,6 +1843,8 @@ static ssize_t generic_file_buffered_read(struct kiocb
> *iocb,
>
> page = find_get_page(mapping, index);
> if (!page) {
> + if (iocb->ki_flags & IOCB_NOWAIT)
> + goto would_block;
> page_cache_sync_readahead(mapping,
> ra, filp,
> index, last_index - index);
> @@ -1948,6 +1950,11 @@ static ssize_t generic_file_buffered_read(struct kiocb
> *iocb,
> continue;
>
> page_not_up_to_date:
> + if (iocb->ki_flags & IOCB_NOWAIT) {
> + put_page(page);
> + goto would_block;
> + }
> +
This potentially could do with a comment to say that from here we will
either block on the page lock or on the read operation but it's fairly
obvious from context. What is potentially less obvious is that a page
lock contention ends up here. That could be due to a read operation taking
place in parallel but also page migrations, page scanning etc. They are all
blocking operations but the duration could be anthing from nanoseconds to
milliseconds. That *might* be surprising to some who notice they got EAGAIN
on data that should be cache resident due to the page being activated on
the LRU, being migrated etc.
That sort of gotcha might belong in the man page but it is an implementation
detail so maybe the man page should note that EAGAIN can occur for cache
resident data in some circumstances.
I can't actually see anything wrong with the patch so...
Acked-by: Mel Gorman
--
Mel Gorman
SUSE Labs
[PATCH] block: add io queue depth show
show io queue depth.
Signed-off-by: weiping zhang
---
block/blk-sysfs.c | 11 +++
include/linux/blkdev.h | 5 +
2 files changed, 16 insertions(+)
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 27aceab..66cba2b 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -256,6 +256,11 @@ static ssize_t queue_max_hw_sectors_show(struct
request_queue *q, char *page)
return queue_var_show(max_hw_sectors_kb, (page));
}
+static ssize_t queue_io_queue_depth_show(struct request_queue *q, char *page)
+{
+ return queue_var_show(queue_io_queue_depth(q), (page));
+}
+
#define QUEUE_SYSFS_BIT_FNS(name, flag, neg) \
static ssize_t \
queue_show_##name(struct request_queue *q, char *page) \
@@ -678,6 +683,11 @@ static struct queue_sysfs_entry queue_wb_lat_entry = {
.store = queue_wb_lat_store,
};
+static struct queue_sysfs_entry queue_io_queue_depth_entry = {
+ .attr = {.name = "io_queue_depth", .mode = S_IRUGO },
+ .show = queue_io_queue_depth_show,
+};
+
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
static struct queue_sysfs_entry throtl_sample_time_entry = {
.attr = {.name = "throttle_sample_time", .mode = S_IRUGO | S_IWUSR },
@@ -719,6 +729,7 @@ static struct attribute *default_attrs[] = {
&queue_dax_entry.attr,
&queue_wb_lat_entry.attr,
&queue_poll_delay_entry.attr,
+ &queue_io_queue_depth_entry.attr,
#ifdef CONFIG_BLK_DEV_THROTTLING_LOW
&throtl_sample_time_entry.attr,
#endif
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 25f6a0c..bcd0af4 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1405,6 +1405,11 @@ static inline unsigned int queue_max_hw_sectors(struct
request_queue *q)
return q->limits.max_hw_sectors;
}
+static inline unsigned int queue_io_queue_depth(struct request_queue *q)
+{
+ return q->queue_depth;
+}
+
static inline unsigned short queue_max_segments(struct request_queue *q)
{
return q->limits.max_segments;
--
2.9.4
Re: [PATCH 1/4] fs: pass iocb to do_generic_file_read
On Thu, Jul 06, 2017 at 08:30:16AM -0700, Christoph Hellwig wrote: > And rename it to the more descriptive generic_file_buffered_read while > at it. > > Signed-off-by: Christoph Hellwig Acked-by: Mel Gorman -- Mel Gorman SUSE Labs
