Re: [PATCH 1/3] blk-throttle: support io delay stats

Ping... Thanks, Joseph On 19/7/25 11:03, Joseph Qi wrote: > Add blkio.throttle.io_service_time and blkio.throttle.io_wait_time to > get per-cgroup io delay statistics in blk-throttle layer. > io_service_time represents the time spent after io throttle to io > completion, while

[PATCH 2/3] blk-throttle: add counter for completed io

Now we have counters for wait_time and service_time, so add another counter for completed ios, then the average latency can be measured. Signed-off-by: Joseph Qi --- block/blk-throttle.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/block/blk-throttle.c b

[PATCH 3/3] blk-throttle: add throttled io/bytes counter

Add another 2 interfaces to stat io throttle information: blkio.throttle.total_io_queued blkio.throttle.total_bytes_queued These interfaces are used for monitoring throttled io/bytes and analyzing if delay has relations with io throttle. Signed-off-by: Joseph Qi --- block/blk-throttle.c

[PATCH 1/3] blk-throttle: support io delay stats

Add blkio.throttle.io_service_time and blkio.throttle.io_wait_time to get per-cgroup io delay statistics in blk-throttle layer. io_service_time represents the time spent after io throttle to io completion, while io_wait_time represents the time spent on throttle queue. Signed-off-by: Joseph Qi

Re: [bug report][stable] xfstests:generic/538 failed on xfs

On 19/6/5 21:57, Brian Foster wrote: > On Wed, Jun 05, 2019 at 02:42:27PM +0200, gregkh wrote: >> On Wed, Jun 05, 2019 at 08:21:44PM +0800, Alvin Zheng wrote: >>> Hi, >>> I was using kernel v4.19.48 and found that it cannot pass the generic/538 >>> on xfs. The error output is as follows: >> >

Re: [RFC] mm: Replace all open encodings for NUMA_NO_NODE

For ocfs2 part, node means host in the cluster, not NUMA node. Thanks, Joseph On 18/11/12 10:41, Anshuman Khandual wrote: > At present there are multiple places where invalid node number is encoded > as -1. Even though implicitly understood it is always better to have macros > in there. Replace t

Re: testing io.low limit for blk-throttle

Hi Paolo, On 18/4/27 01:27, Paolo Valente wrote: > > >> Il giorno 25 apr 2018, alle ore 14:13, Joseph Qi ha >> scritto: >> >> Hi Paolo, >> > > Hi Joseph > >> ... >> Could you run blktrace as well when testing your case? There are seve

Re: testing io.low limit for blk-throttle

Hi Jianchao, On 18/4/27 10:09, jianchao.wang wrote: > Hi Tejun and Joseph > > On 04/27/2018 02:32 AM, Tejun Heo wrote: >> Hello, >> >> On Tue, Apr 24, 2018 at 02:12:51PM +0200, Paolo Valente wrote: >>> +Tejun (I guess he might be interested in the results below) >> >> Our experiments didn't work

Re: testing io.low limit for blk-throttle

Hi Paolo, On 18/4/24 20:12, Paolo Valente wrote: > > >> Il giorno 23 apr 2018, alle ore 11:01, Joseph Qi ha >> scritto: >> >> >> >> On 18/4/23 15:35, Paolo Valente wrote: >>> >>> >>>> Il giorno 23 apr 2018, alle ore 0

Re: testing io.low limit for blk-throttle

On 18/4/23 15:35, Paolo Valente wrote: > > >> Il giorno 23 apr 2018, alle ore 08:05, Joseph Qi ha >> scritto: >> >> Hi Paolo, > > Hi Joseph, > thanks for chiming in. > >> What's your idle and latency config? > > I didn't s

Re: testing io.low limit for blk-throttle

Hi Paolo, What's your idle and latency config? IMO, io.low will allow others run more bandwidth if cgroup's average idle time is high or latency is low. In such cases, low limit won't get guaranteed. Thanks, Joseph On 18/4/22 17:23, Paolo Valente wrote: > Hi Shaohua, all, > at last, I started tes

Re: [PATCH v3] blk-mq: Avoid that submitting a bio concurrently with device removal triggers a crash

_queue_enter() / blk_queue_exit(). > > Reported-by: Ming Lei > Fixes: a063057d7c73 ("block: Fix a race between request queue removal and the > block cgroup controller") > Signed-off-by: Bart Van Assche > Cc: Ming Lei > Cc: Joseph Qi I've tested using the followi

Re: [block regression] kernel oops triggered by removing scsi device dring IO

Hi Bart, On 18/4/9 12:47, Bart Van Assche wrote: > On Sun, 2018-04-08 at 12:21 +0800, Ming Lei wrote: >> The following kernel oops is triggered by 'removing scsi device' during >> heavy IO. > > Is the below patch sufficient to fix this? > > Thanks, > > Bart. > > > Subject: blk-mq: Avoid that

Re: [block regression] kernel oops triggered by removing scsi device dring IO

Hi Bart, On 18/4/8 22:50, Bart Van Assche wrote: > On Sun, 2018-04-08 at 12:21 +0800, Ming Lei wrote: >> The following kernel oops is triggered by 'removing scsi device' during >> heavy IO. > > How did you trigger this oops? > I can reproduce this oops by the following steps: 1) start a fio job

[PATCH] blk-throttle: fix typo in blkg_print_stat_ios() comments

Signed-off-by: Joseph Qi --- block/blk-cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c index 1c16694..87367d4 100644 --- a/block/blk-cgroup.c +++ b/block/blk-cgroup.c @@ -640,7 +640,7 @@ int blkg_print_stat_bytes(struct

Re: [block regression] kernel oops triggered by removing scsi device dring IO

This is because scsi_remove_device() will call blk_cleanup_queue(), and then all blkgs have been destroyed and root_blkg is NULL. Thus tg is NULL and trigger NULL pointer dereference when get td from tg (tg->td). It seems that we cannot simply move blkcg_exit_queue() up to blk_cleanup_queue(). Tha

[PATCH v6] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

struction (especially blkg_put()) into blkcg_css_free(), which should be the right way as discussed. Fixes: ae1188963611 ("blkcg: consolidate blkg creation in blkcg_bio_issue_check()") Reported-by: Jiufei Xue Signed-off-by: Joseph Qi Acked-by:

Re: [PATCH v5] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

Hello Tejun, Thanks for your quick response. On 18/3/14 22:09, Tejun Heo wrote: > Hello, > > On Wed, Mar 14, 2018 at 02:18:04PM +0800, Joseph Qi wrote: >> Fixes: ae1188963611 ("blkcg: consolidate blkg creation in >> blkcg_bio_issue_check()") >>

[PATCH v5] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

struction (especially blkg_put()) into blkcg_css_free(), which should be the right way as discussed. Fixes: ae1188963611 ("blkcg: consolidate blkg creation in blkcg_bio_issue_check()") Reported-by: Jiufei Xue Cc: sta...@vger.kernel.org #4.3+ Signed-off-by:

Re: [PATCH v3] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

Fine, I will do the corresponding changes and post v5. Thanks, Joseph On 18/3/14 04:19, Tejun Heo wrote: > Hello, Joseph. > > On Mon, Mar 05, 2018 at 11:03:16PM +0800, Joseph Qi wrote: >> +static void blkg_pd_offline(struct blkcg_gq *blkg) >> +{ >> +int i; >&

Re: [PATCH v4] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

Hello Tejun, Could you please help review this version? Thanks, Joseph On 18/3/6 11:53, Joseph Qi wrote: > We've triggered a WARNING in blk_throtl_bio() when throttling writeback > io, which complains blkg->refcnt is already 0 when calling blkg_get(), > and then kernel crashes

[PATCH v4] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

blkcg_css_offline(), and move the rest destruction (especially blkg_put()) into blkcg_css_free(), which should be the right way as discussed. Fixes: ae1188963611 ("blkcg: consolidate blkg creation in blkcg_bio_issue_check()") Reported-by: Jiufei Xue Cc: sta...@vger.kernel.org #4.3+ S

[PATCH v3] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

blkcg_css_offline(), and move the rest destruction (especially blkg_put()) into blkcg_css_free(), which should be the right way as discussed. Fixes: ae1188963611 ("blkcg: consolidate blkg creation in blkcg_bio_issue_check()") Reported-by: Jiufei Xue Cc: sta...@vger.kernel.org #4.3+ S

Re: [PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

On 18/3/5 04:23, Tejun Heo wrote: > Hello, Joseph. > > Sorry about late reply. > > On Wed, Feb 28, 2018 at 02:52:10PM +0800, Joseph Qi wrote: >> In current code, I'm afraid pd_offline_fn() as well as the rest >> destruction have to be called together und

Re: [PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

Hi Tejun, On 18/2/28 02:33, Tejun Heo wrote: > Hello, Joseph. > > On Sat, Feb 24, 2018 at 09:45:49AM +0800, Joseph Qi wrote: >>> IIRC, as long as the blkcg and the device are there, the blkgs aren't >>> gonna be destroyed. So, if you have a ref to the bl

Re: [PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

Hi Tejun, Could you please help take a look at this and give a confirmation? Thanks, Joseph On 18/2/24 09:45, Joseph Qi wrote: > Hi Tejun, > > On 18/2/23 22:23, Tejun Heo wrote: >> Hello, >> >> On Fri, Feb 23, 2018 at 09:56:54AM +0800, xuejiufei wrote: >>>

Re: [PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

Hi Tejun, On 18/2/23 22:23, Tejun Heo wrote: > Hello, > > On Fri, Feb 23, 2018 at 09:56:54AM +0800, xuejiufei wrote: >>> On Thu, Feb 22, 2018 at 02:14:34PM +0800, Joseph Qi wrote: >>>> I still don't get how css_tryget can work here. >>>> >>&g

Re: [PATCH v4 6/6] block: Fix a race between request queue removal and the block cgroup controller

now; > (6) but unlock internal lock. > > This change is safe because only the SCSI core and the NVME core keep > a reference on a request queue after having called blk_cleanup_queue(). > Neither driver accesses any of the removed data structures between its > blk_cleanup_queue() an

Re: [PATCH v4 5/6] block: Fix a race between the cgroup code and request queue initialization

blk_alloc_queue() call in the driver into a > blk_alloc_queue_node() call and remove the explicit .queue_lock > initialization. Additionally, initialize the spin lock that will > be used as queue lock earlier if necessary. > > Reported-by: Joseph Qi > Signed-off-by: Bart Van Ass

Re: [PATCH v4 3/6] zram: Delete gendisk before cleaning up the request queue

On 18/2/23 09:08, Bart Van Assche wrote: > Remove the disk, partition and bdi sysfs attributes before cleaning up > the request queue associated with the disk. > > Signed-off-by: Bart Van Assche > Cc: Minchan Kim > Cc: Nitin Gupta > Cc: Sergey Senozhatsky Looks good. Reviewed-by: Joseph Qi

Re: [PATCH v4 2/6] md: Delete gendisk before cleaning up the request queue

On 18/2/23 09:08, Bart Van Assche wrote: > Remove the disk, partition and bdi sysfs attributes before cleaning up > the request queue associated with the disk. > > Signed-off-by: Bart Van Assche > Cc: Shaohua Li Looks good. Reviewed-by: Joseph Qi

Re: [PATCH v4 1/6] block/loop: Delete gendisk before cleaning up the request queue

Reinecke > Cc: Ming Lei Looks good. Reviewed-by: Joseph Qi

Re: [PATCH v4 4/6] block: Add a third argument to blk_alloc_queue_node()

On 18/2/23 09:08, Bart Van Assche wrote: > This patch does not change any functionality. > > Signed-off-by: Bart Van Assche > Cc: Christoph Hellwig > Cc: Joseph Qi > Cc: Philipp Reisner > Cc: Ulf Hansson > Cc: Kees Cook Looks good. Reviewed-by: Joseph Qi

Re: [PATCH] blk-throttle: avoid multiple counting for same bio

On 18/2/23 11:33, Chengguang Xu wrote: > Hi Tejun, > > Sorry for delayed reply, I was on vacation last week. > > The problem still exists in current code of 4.16.0-rc2, > detail test information is below, if further info is needed please let me > know. > > Thanks. > That's true, the issue S

Re: [PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

Hi Tejun, Sorry for the delayed reply. On 18/2/13 01:11, Tejun Heo wrote: > Hello, Joseph. > > On Fri, Feb 09, 2018 at 10:15:19AM +0800, Joseph Qi wrote: >> IIUC, we have to identify it is in blkcg_css_offline now which will >> blkg_put. Since percpu_ref_kill_and_confirm

Re: [PATCH v3 3/3] block: Fix a race between request queue removal and the block cgroup controller

removed data structures between its > blk_cleanup_queue() and blk_put_queue() calls. > > Reported-by: Joseph Qi > Signed-off-by: Bart Van Assche > Cc: Jan Kara > --- > block/blk-core.c | 31 +++ > block/blk-sysfs.c | 7 --- >

Re: [PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

Hi Tejun, On 18/2/8 23:23, Tejun Heo wrote: > Hello, Joseph. > > On Thu, Feb 08, 2018 at 10:29:43AM +0800, Joseph Qi wrote: >> So you mean checking css->refcnt to prevent the further use of >> blkg_get? I think it makes sense. > > Yes. > >> IMO, we sh

Re: [PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

Hi Tejun, Thanks very much for reviewing this patch. On 18/2/8 05:38, Tejun Heo wrote: > Hello, Joseph. > > On Wed, Feb 07, 2018 at 04:40:02PM +0800, Joseph Qi wrote: >> writeback kworker >> blkcg_bio_issue_check >> rcu_read_lock >> bl

[PATCH v2] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

188963611 ("blkcg: consolidate blkg creation in blkcg_bio_issue_check()") Reported-by: Jiufei Xue Signed-off-by: Joseph Qi Cc: sta...@vger.kernel.org --- block/blk-cgroup.c | 2 +- block/blk-throttle.c | 30 ++ block/cfq-iosched.c| 33 +

[PATCH] blk-throttle: fix race between blkcg_bio_issue_check and cgroup_rmdir

sue_check()") Reported-by: Jiufei Xue Signed-off-by: Joseph Qi CC: sta...@vger.kernel.org --- block/blk-cgroup.c | 2 +- block/blk-throttle.c | 29 + block/cfq-iosched.c| 33 +++-- include/linux/blk-cgroup.h | 27 ++

Re: [PATCH v2 2/2] block: Fix a race between the throttling code and request queue initialization

Hi Bart, On 18/2/3 00:21, Bart Van Assche wrote: > On Fri, 2018-02-02 at 09:02 +0800, Joseph Qi wrote: >> We triggered this race when using single queue. I'm not sure if it >> exists in multi-queue. > > Regarding the races between modifying the queue_lock pointer and

Re: [PATCH v2 2/2] block: Fix a race between the throttling code and request queue initialization

Hi Bart, On 18/2/2 00:16, Bart Van Assche wrote: > On Thu, 2018-02-01 at 09:53 +0800, Joseph Qi wrote: >> I'm afraid the risk may also exist in blk_cleanup_queue, which will >> set queue_lock to to the default internal lock. >> >> spin_lock_irq(lock); >>

Re: [PATCH v2 2/2] block: Fix a race between the throttling code and request queue initialization

Hi Bart, On 18/2/1 07:53, Bart Van Assche wrote: > Initialize the request queue lock earlier such that the following > race can no longer occur: > > blk_init_queue_node blkcg_print_blkgs > blk_alloc_queue_node (1) > q->queue_lock = &q->__queue_lock (2) > blkcg_init_queue

Re: [RFC] hard LOCKUP caused by race between blk_init_queue_node and blkcg_print_blkgs

Hi Bart, Thanks very much for the quick response. On 18/1/31 05:19, Bart Van Assche wrote: > On Tue, 2018-01-30 at 19:21 +0800, Joseph Qi wrote: >> Hi Jens and Folks, >> >> Recently we've gotten a hard LOCKUP issue. After investigating the issue >> we've fou

[RFC] hard LOCKUP caused by race between blk_init_queue_node and blkcg_print_blkgs

Hi Jens and Folks, Recently we've gotten a hard LOCKUP issue. After investigating the issue we've found a race between blk_init_queue_node and blkcg_print_blkgs. The race is described below. blk_init_queue_node blkcg_print_blkgs blk_alloc_queue_node (1) q->queue_lock = &q->_

[PATCH RESEND 3/3] blk-throttle: do downgrade/upgrade check when issuing io to lower layer

o low limit not guaranteed most of time. Fix this case by moving check logic down, in which we are ready to issue io to lower layer. Signed-off-by: Joseph Qi Reviewed-by: Jiufei Xue --- block/blk-throttle.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/

[PATCH RESEND 1/3] blk-throttle: fix NULL pointer dereference risk in throtl_select_dispatch

tg in throtl_select_dispatch is used first and then do check. Since tg may be NULL, it has potential NULL pointer dereference risk. So fix it. Signed-off-by: Joseph Qi Reviewed-by: Jiufei Xue --- block/blk-throttle.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block

[PATCH RESEND 2/3] blk-throttle: support only configure leaf nodes

x27;t have low limit, ignore checking it and just depend on child's decision. Note that we do not support only configure intermediate nodes. Signed-off-by: Joseph Qi Reviewed-by: Jiufei Xue --- block/blk-throttle.c | 9 + 1 file changed, 9 insertions(+) diff --git a/block/blk-throttle

Re: [PATCH v3 RESEND 2/2] blk-throttle: fix wrong initialization in case of dm device

Hi Mike, On 18/1/19 11:29, Mike Snitzer wrote: > On Thu, Jan 18 2018 at 10:09pm -0500, > Joseph Qi wrote: > >> From: Joseph Qi >> >> DM device sets QUEUE_FLAG_NONROT after the queue is registered. That is >> to mean, the previous initialization in blk_throtl_r

[PATCH v3 RESEND 2/2] blk-throttle: fix wrong initialization in case of dm device

From: Joseph Qi DM device sets QUEUE_FLAG_NONROT after the queue is registered. That is to mean, the previous initialization in blk_throtl_register_queue is wrong in this case. Fix it by checking and then updating the info during root tg initialization as we don't have a better choice. S

Re: [PATCH v3 RESEND 1/2] blk-throttle: track read and write request individually

Sure, I will resend it. Thanks. Joseph On 18/1/19 10:52, Jens Axboe wrote: > On 1/18/18 7:11 PM, Joseph Qi wrote: >> Hi Jens, >> Could you please pick the two pending patches for 4.16? >> They all have been reviewed by Shaohua. > > Sorry, I guess I forgot about t

Re: [PATCH v3 RESEND 1/2] blk-throttle: track read and write request individually

Hi Jens, Could you please pick the two pending patches for 4.16? They all have been reviewed by Shaohua. Thanks, Joseph On 18/1/8 20:05, Joseph Qi wrote: > A polite ping for the two pending patches... > > Thanks, > Joseph > > On 17/11/24 13:13, Jens Axboe wrote: >>

Re: [PATCH v3 RESEND 1/2] blk-throttle: track read and write request individually

A polite ping for the two pending patches... Thanks, Joseph On 17/11/24 13:13, Jens Axboe wrote: > On 11/23/2017 06:31 PM, Joseph Qi wrote: >> Hi Jens, >> Could you please give your advice for the two patches or pick them up if >> you think they are good? > >

[PATCH 3/3] blk-throttle: do downgrade/upgrade check when issuing io to lower layer

From: Joseph Qi Currently downgrade/upgrade check is done when io firstly comes to block throttle layer. In case of writeback, a large number of ios will firstly be throttled in throttle queue and then dispatched when timer kicked, which won't be checked because REQ_THROTTLED is set. This

[PATCH 2/3] blk-throttle: support only configure leaf nodes

From: Joseph Qi Currently if we only configure leaf nodes, downgrade check won't function properly as parent's last low overflow time is meaningless and always returns now, thus it will be treated always run above low limit and doesn't have to do downgrade. In this case, since

[PATCH 1/3] blk-throttle: fix NULL pointer dereference risk in throtl_select_dispatch

From: Joseph Qi tg in throtl_select_dispatch is used first and then do check. Since tg may be NULL, it has potential NULL pointer dereference risk. So fix it. Signed-off-by: Joseph Qi --- block/blk-throttle.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/blk

Re: [RFC] distinguish foreground and background IOs in block throttle

Hi Paolo, On 17/12/27 20:36, Paolo Valente wrote: > > >> Il giorno 25 dic 2017, alle ore 03:44, xuejiufei ha >> scritto: >> >> Hi all, >> >> Cgroup writeback is supported since v4.2. I found there exists a >> problem in the following case. >> >> A cgroup may send both buffer and direct/sync IO

Re: [PATCH v3 RESEND 1/2] blk-throttle: track read and write request individually

Hi Jens, Could you please give your advice for the two patches or pick them up if you think they are good? Thanks, Joseph On 17/11/21 09:38, Joseph Qi wrote: > From: Joseph Qi > > In mixed read/write workload on SSD, write latency is much lower than > read. But now we only trac

[PATCH v3 2/2] blk-throttle: fix wrong initialization in case of dm device

From: Joseph Qi DM device sets QUEUE_FLAG_NONROT after the queue is registered. That is to mean, the previous initialization in blk_throtl_register_queue is wrong in this case. Fix it by checking and then updating the info during root tg initialization as we don't have a better choice. S

[PATCH v3 RESEND 1/2] blk-throttle: track read and write request individually

From: Joseph Qi In mixed read/write workload on SSD, write latency is much lower than read. But now we only track and record read latency and then use it as threshold base for both read and write io latency accounting. As a result, write io latency will always be considered as good and

Re: [PATCH v2 2/2] blk-throttle: fix wrong initialization in case of dm device

On 17/11/21 01:15, Shaohua Li wrote: > On Mon, Nov 20, 2017 at 10:00:27AM +0800, Joseph Qi wrote: >> From: Joseph Qi >> >> dm device set QUEUE_FLAG_NONROT in resume, which is after register >> queue. That is to mean, the previous initialization in >> blk_throt

Re: [PATCH v2 2/2] blk-throttle: fix wrong initialization in case of dm device

Hi Mike, On 17/11/21 05:02, Mike Snitzer wrote: > On Sun, Nov 19, 2017 at 9:00 PM, Joseph Qi wrote: >> From: Joseph Qi >> >> dm device set QUEUE_FLAG_NONROT in resume, which is after register >> queue. That is to mean, the previous initialization in >> blk_throt

[PATCH v2 2/2] blk-throttle: fix wrong initialization in case of dm device

From: Joseph Qi dm device set QUEUE_FLAG_NONROT in resume, which is after register queue. That is to mean, the previous initialization in blk_throtl_register_queue is wrong in this case. Fix it by checking and then updating the info during root tg initialization as we don't have a better c

[PATCH v2 RESEND 1/2] blk-throttle: track read and write request individually

From: Joseph Qi In mixed read/write workload on SSD, write latency is much lower than read. But now we only track and record read latency and then use it as threshold base for both read and write io latency accounting. As a result, write io latency will always be considered as good and

[PATCH] blk-throttle: fix wrong initialization in case of dm device

From: Joseph Qi dm device set QUEUE_FLAG_NONROT in resume, which is after register queue. That is to mean, the previous initialization in blk_throtl_register_queue is wrong in this case. Fix it by checking and then updating the info during root tg initialization as we don't have a better c

Re: [PATCH v2] blk-throttle: track read and write request individually

Hi Jens, Could you please pick this patch? Thanks, Joseph On 17/10/13 01:13, Shaohua Li wrote: > On Thu, Oct 12, 2017 at 05:15:46PM +0800, Joseph Qi wrote: >> From: Joseph Qi >> >> In mixed read/write workload on SSD, write latency is much lower than >> read. But n

[PATCH v2] blk-throttle: track read and write request individually

From: Joseph Qi In mixed read/write workload on SSD, write latency is much lower than read. But now we only track and record read latency and then use it as threshold base for both read and write io latency accounting. As a result, write io latency will always be considered as good and

Re: [PATCH] blk-throttle: track read and write request individually

On 17/10/12 03:21, Shaohua Li wrote: > On Wed, Oct 11, 2017 at 05:53:34PM +0800, Joseph Qi wrote: >> From: Joseph Qi >> >> In mixed read/write workload on SSD, write latency is much lower than >> read. But now we only track and record read latency and then use it as

[PATCH] blk-throttle: track read and write request individually

From: Joseph Qi In mixed read/write workload on SSD, write latency is much lower than read. But now we only track and record read latency and then use it as threshold base for both read and write io latency accounting. As a result, write io latency will always be considered as good and

[PATCH v2] blk-throttle: fix possible io stall when upgrade to max

From: Joseph Qi There is a case which will lead to io stall. The case is described as follows. /test1 |-subtest1 /test2 |-subtest2 And subtest1 and subtest2 each has 32 queued bios already. Now upgrade to max. In throtl_upgrade_state, it will try to dispatch bios as follows: 1) tg=subtest1

Re: [PATCH] blk-throttle: fix possible io stall when doing upgrade

On 17/9/28 11:48, Joseph Qi wrote: > Hi Shahua, > > On 17/9/28 05:38, Shaohua Li wrote: >> On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote: >>> >>> >>> On 17/9/26 10:48, Shaohua Li wrote: >>>> On Tue, Sep 26, 2017 at 09:06:57AM +0

Re: [PATCH] blk-throttle: fix possible io stall when doing upgrade

Hi Shahua, On 17/9/28 05:38, Shaohua Li wrote: > On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote: >> >> >> On 17/9/26 10:48, Shaohua Li wrote: >>> On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote: >>>> Hi Shaohua, >>>> >

Re: [PATCH] blk-throttle: fix possible io stall when doing upgrade

On 17/9/26 10:48, Shaohua Li wrote: > On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote: >> Hi Shaohua, >> >> On 17/9/26 01:22, Shaohua Li wrote: >>> On Mon, Sep 25, 2017 at 06:46:42PM +0800, Joseph Qi wrote: >>>> From: Joseph Qi >>

Re: [PATCH] blk-throttle: fix possible io stall when doing upgrade

Hi Shaohua, On 17/9/26 01:22, Shaohua Li wrote: > On Mon, Sep 25, 2017 at 06:46:42PM +0800, Joseph Qi wrote: >> From: Joseph Qi >> >> Currently it will try to dispatch bio in throtl_upgrade_state. This may >> lead to io stall in the following case. >> Say

[PATCH] blk-throttle: fix possible io stall when doing upgrade

From: Joseph Qi Currently it will try to dispatch bio in throtl_upgrade_state. This may lead to io stall in the following case. Say the hierarchy is like: /-test1 |-subtest1 and subtest1 has 32 queued bios now. throtl_pending_timer_fnthrotl_upgrade_state

Re: [PATCH V6 00/18] blk-throttle: add .low limit

Hi Shaohua, On 17/9/6 05:02, Shaohua Li wrote: > On Thu, Aug 31, 2017 at 09:24:23AM +0200, Paolo VALENTE wrote: >> >>> Il giorno 15 gen 2017, alle ore 04:42, Shaohua Li ha scritto: >>> >>> Hi, >>> >>> cgroup still lacks a good iocontroller. CFQ works well for hard disk, but >>> not >>> much for

[PATCH RESEND] blk-throttle: fix potential NULL pointer dereference in throtl_select_dispatch

From: Joseph Qi Since throtl_rb_first may return NULL, so it should check tg first and then use it. Signed-off-by: Joseph Qi --- block/blk-throttle.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index a7285bf..c1d2c5b 100644

blk-throttle: fix potential NULL pointer dereference in throtl_select_dispatch

From: Joseph Qi Since throtl_rb_first may return NULL, so it should check tg first and then use it. Signed-off-by: Joseph Qi --- block/blk-throttle.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/block/blk-throttle.c b/block/blk-throttle.c index a7285bf..c1d2c5b 100644

[PATCH] blk-throttle: fix NULL pointer dereference in throtl_schedule_pending_timer

From: Joseph Qi I have encountered a NULL pointer dereference in throtl_schedule_pending_timer: [ 413.735396] BUG: unable to handle kernel NULL pointer dereference at 0038 [ 413.735535] IP: [] throtl_schedule_pending_timer+0x3f/0x210 [ 413.735643] PGD 22c8cf067 PUD

blk-mq: free callback if error occurs in blk_mq_init_allocated_queue

From: Joseph Qi If error occurs, we have to free the allocated callback in blk_mq_init_allocated_queue to avoid memory leaking. Fixes: 34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting") Signed-off-by: Joseph Qi --- block/blk-mq.c | 4 +++- 1 file changed, 3