linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Changheun Lee <nanich.lee@samsung.com>
To: hch@infradead.org
Cc: Johannes.Thumshirn@wdc.com, alex_y_xu@yahoo.ca,
	asml.silence@gmail.com, axboe@kernel.dk, bgoncalv@redhat.com,
	bvanassche@acm.org, damien.lemoal@wdc.com,
	gregkh@linuxfoundation.org, jaegeuk@kernel.org,
	jisoo2146.oh@samsung.com, junho89.kim@samsung.com,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	ming.lei@redhat.com, mj0123.lee@samsung.com,
	nanich.lee@samsung.com, osandov@fb.com, patchwork-bot@kernel.org,
	seunghwan.hyun@samsung.com, sookwan7.kim@samsung.com,
	tj@kernel.org, tom.leiming@gmail.com, woosung2.lee@samsung.com,
	yi.zhang@redhat.com, yt0928.kim@samsung.com
Subject: Re: [PATCH v10 0/1] bio: limit bio max size
Date: Fri, 14 May 2021 15:32:41 +0900	[thread overview]
Message-ID: <20210514063241.22260-1-nanich.lee@samsung.com> (raw)
In-Reply-To: <YJ0MJe1Gc5XMV1gB@infradead.org>

> FYI, I still think this whole limit is a bad idea, and instead we
> need to fix the algorithms to not waste time iterating over the bios
> again and again in non-optimal ways.  I still haven't seen an answer
> if your original latency problems are reproducable with the iomap
> direct I/O implementation, and we've also not even started the work on
> making some of the common iterators less stupid.

Sorry. I missed your request.
Actually iomap direct I/O implementaion in f2fs, or do_direct_IO() is not
easy to me. So I tested it on ext4 environment. iomap is applied in ext4
already. As a result, same performance degradation is reproduced.

I tested 512MB file read with direct I/O. and chunk size is 64MB.
 - on SCSI disk, with no limit of bio max size(4GB) : avg. 630 MB/s
 - on SCSI disk, with limit bio max size to 1MB     : avg. 645 MB/s
 - on ramdisk, with no limit of bio max size(4GB)   : avg. 2749 MB/s
 - on ramdisk, with limit bio max size to 1MB       : avg. 3068 MB/s

I set ramdisk environment as below.
 - dd if=/dev/zero of=/mnt/ramdisk.img bs=$((1024*1024)) count=1024
 - mkfs.ext4 /mnt/ramdisk.img
 - mkdir /mnt/ext4ramdisk
 - mount -o loop /mnt/ramdisk.img /mnt/ext4ramdisk

With low performance disk, bio submit delay caused by large bio size is
not big protion. So it can't be feel easily. But it will be shown in high
performance disk.

Limit bio size is not affact to stacked driver. it's for physical disk
driver. As your advise, algorithm fixing to remove waste time is needed for
each module. I agree with you. But I think it might be good submitting bio
when bio size is over than disk transfer size logically too.

Thanks,
Changheun Lee.

  parent reply	other threads:[~2021-05-14  6:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210513102018epcas1p2a69f8e50cdf8380e433aea1a9303d04c@epcas1p2.samsung.com>
2021-05-13 10:02 ` Changheun Lee
     [not found]   ` <CGME20210513102019epcas1p35d6740527dacd9bff7d8b07316e4cbfd@epcas1p3.samsung.com>
2021-05-13 10:02     ` [PATCH v10 1/1] " Changheun Lee
2021-05-13 11:23   ` [PATCH v10 0/1] " Christoph Hellwig
     [not found]     ` <CGME20210514065054epcas1p4bd5c92a59d4010da4447ef62f65fdd4b@epcas1p4.samsung.com>
2021-05-14  6:32       ` Changheun Lee [this message]
2021-05-17 10:11         ` Christoph Hellwig
     [not found]           ` <CGME20210526034859epcas1p3b3ab803406c983df431f89b6f9097f08@epcas1p3.samsung.com>
2021-05-26  3:30             ` Changheun Lee

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=20210514063241.22260-1-nanich.lee@samsung.com \
    --to=nanich.lee@samsung.com \
    --cc=Johannes.Thumshirn@wdc.com \
    --cc=alex_y_xu@yahoo.ca \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=bgoncalv@redhat.com \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@wdc.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jaegeuk@kernel.org \
    --cc=jisoo2146.oh@samsung.com \
    --cc=junho89.kim@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=mj0123.lee@samsung.com \
    --cc=osandov@fb.com \
    --cc=patchwork-bot@kernel.org \
    --cc=seunghwan.hyun@samsung.com \
    --cc=sookwan7.kim@samsung.com \
    --cc=tj@kernel.org \
    --cc=tom.leiming@gmail.com \
    --cc=woosung2.lee@samsung.com \
    --cc=yi.zhang@redhat.com \
    --cc=yt0928.kim@samsung.com \
    --subject='Re: [PATCH v10 0/1] bio: limit bio max size' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).