Re: [for-416 PATCH v2] bcache: writeback: collapse contiguous IO better

Hi Tang Junhui--- On 12/28/2017 06:00 PM, tang.jun...@zte.com.cn wrote: > LGTM, I would like it much more if MAX_WRITEBACKS_IN_PASS(5) defines a > little bigger value. Yes-- we can always turn it up further depending on experience. 5 was chosen to provide a clear benefit without changing

Re: regression 4.15-rc: kernel oops in dm-multipath

On 12/22/2017 09:10 PM, Christian Borntraeger wrote: > I will give that commit a try. Thanks. > > On 12/22/2017 05:00 PM, Bart Van Assche wrote: >> On Fri, 2017-12-22 at 10:53 +0100, Christian Borntraeger wrote: >>> any quick ideas? >> >> Hello Christian, >> >> Was commit afc567a4977b ("dm

Re: [PATCH IMPROVEMENT] block, bfq: limit sectors served with interactive weight raising

Hi. On čtvrtek 28. prosince 2017 12:19:17 CET Paolo Valente wrote: > To maximise responsiveness, BFQ raises the weight, and performs device > idling, for bfq_queues associated with processes deemed as > interactive. In particular, weight raising has a maximum duration, > equal to the time needed

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 22, 2017 at 08:04:23AM -0600, Bruno Wolff III wrote: > On Fri, Dec 22, 2017 at 21:20:10 +0800, > weiping zhang wrote: > >2017-12-22 12:53 GMT+08:00 Bruno Wolff III : > >>On Thu, Dec 21, 2017 at 17:16:03 -0600, > >> Bruno Wolff III

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Fri, Dec 22, 2017 at 08:04:23AM -0600, Bruno Wolff III wrote: > On Fri, Dec 22, 2017 at 21:20:10 +0800, > weiping zhang wrote: > >2017-12-22 12:53 GMT+08:00 Bruno Wolff III : > >>On Thu, Dec 21, 2017 at 17:16:03 -0600, > >> Bruno Wolff III

Re: [RFC] blk-throttle: export io_serviced_recursive, io_service_bytes_recursive

2017-12-11 23:17 GMT+08:00 Tejun Heo : > On Mon, Dec 11, 2017 at 10:56:25PM +0800, weiping zhang wrote: >> export these two interface for cgroup-v1. >> >> Signed-off-by: weiping zhang > > Acked-by: Tejun Heo > > Thanks. > Hi Jens,

Re: [for-4.16 PATCH v2 1/5] block: establish request failover callback

On Fri, Dec 29 2017 at 5:10am -0500, Christoph Hellwig wrote: > On Tue, Dec 26, 2017 at 10:22:53PM -0500, Mike Snitzer wrote: > > All requests allocated from a request_queue with this callback set can > > failover their requests during completion. > > > > This callback is expected

Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")

On Sat, Dec 30, 2017 at 00:30:32 +0800, weiping zhang wrote: 1. Add proper SELINUX policy that give permission to mdadm for debugfs. 2. Split mdadm into 2 part, Firstly, user proccess mdadm trigger a kwork, secondly kwork will create gendisk)and mdadm wait it

Re: [for-4.16 PATCH v2 2/5] nvme: use request_queue's failover_rq_fn callback for multipath failover

On Fri, Dec 29 2017 at 5:11am -0500, Christoph Hellwig wrote: > Independent on any policy question as raised in reply to the previous > patch: until the ANA (ALUA equivalent for NVMe) spec has been finalized > and our code for it has landed there is no way we're going to expose >

Re: About the try to remove cross-release feature entirely by Ingo

On Fri, Dec 29, 2017 at 04:28:51PM +0900, Byungchul Park wrote: > On Thu, Dec 28, 2017 at 10:51:46PM -0500, Theodore Ts'o wrote: > > On Fri, Dec 29, 2017 at 10:47:36AM +0900, Byungchul Park wrote: > > > > > >(1) The best way: To classify all waiters correctly. > > > > It's really not all

Re: About the try to remove cross-release feature entirely by Ingo

On Fri, Dec 29, 2017 at 3:47 AM, Byungchul Park wrote: > On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote: >> Lockdep works, based on the following: >> >>(1) Classifying locks properly >>(2) Checking relationship between the classes >> >> If (1) is

Re: [PATCH 1/3] nvme/pci: Start request after doorbell ring

Looks fine, although I agree a comment on the q_lock exclusion would be useful.

Re: [PATCH 1/3] nvme/pci: Start request after doorbell ring

On Mon, Dec 25, 2017 at 12:12:52PM +0200, Sagi Grimberg wrote: > >>> But that does bring up the fact if we should always be doing the >>> nvme_process_cq(nvmeq) after IO submission. For direct/hipri IO, >>> maybe it's better to make the submission path faster and skip it? >> >> Yes, I am okay to

Re: [PATCH 2/3] nvme/pci: Remove cq_vector check in IO path

On Wed, Dec 27, 2017 at 11:01:48PM +0200, Sagi Grimberg wrote: > >> Awesome! >> >> Reviewed-by: Sagi Grimberg > > Wait, aren't we unquiesce queues also in nvme_dev_disable? > > Doesn't that rely that the queues are suspended and queue_rq > will fail there? We don't seem to have

Re: About the try to remove cross-release feature entirely by Ingo

On 12/29/2017 5:09 PM, Amir Goldstein wrote: On Fri, Dec 29, 2017 at 3:47 AM, Byungchul Park wrote: On Wed, Dec 13, 2017 at 03:24:29PM +0900, Byungchul Park wrote: Lockdep works, based on the following: (1) Classifying locks properly (2) Checking relationship

Re: [PATCH 3/3] block: Polling completion performance optimization

On Thu, Dec 21, 2017 at 02:34:00PM -0700, Keith Busch wrote: > It would be nice, but the driver doesn't know a request's completion > is going to be a polled. We can trivially set a REQ_POLL bit. In fact my initial patch kit had those on the insitence of Jens, but then I removed it because we

Re: [PATCH V2 1/6] blk-mq: quiesce queue before freeing queue

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V2 3/6] blk-mq: quiesce queue during switching io sched and updating nr_requests

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V2 4/6] blk-mq: avoid to map CPU into stale hw queue

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH V2 2/6] blk-mq: support concurrent blk_mq_quiesce_queue()

The quiesce count looks good to me. But I'm really worried about the force unquiesce in nvme. I'd feel much better if we could find a way to move this into the core.

Re: [PATCH V2 5/6] blk-mq: fix race between updating nr_hw_queues and switching io sched

Looks good, Reviewed-by: Christoph Hellwig

Re: [for-4.16 PATCH v2 1/5] block: establish request failover callback

On Tue, Dec 26, 2017 at 10:22:53PM -0500, Mike Snitzer wrote: > All requests allocated from a request_queue with this callback set can > failover their requests during completion. > > This callback is expected to use the blk_steal_bios() interface to > transfer a request's bios back to an

Re: [for-4.16 PATCH v2 2/5] nvme: use request_queue's failover_rq_fn callback for multipath failover

Independent on any policy question as raised in reply to the previous patch: until the ANA (ALUA equivalent for NVMe) spec has been finalized and our code for it has landed there is no way we're going to expose anything from this code based as it will be highly in flux.