Hi There

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your

Re: Circular locking dependency with pblk

On Thu, Oct 05, 2017 at 12:53:50PM +0200, Javier González wrote: > Hi, > > lockdep is reporting a circular dependency when using XFS and pblk, > which I am a bit confused about. > > This happens when XFS sends a number of nested reads and (at least) one > of them hits partially pblk's cache. In

[PATCH v2] block/laptop_mode: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: Jens Axboe Cc: Michal Hocko Cc: Andrew Morton

[PATCH v2] block/aoe: Convert timers to use timer_setup()

In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: Jens Axboe Cc: "Ed L. Cashin" Cc: linux-block@vger.kernel.org Cc:

Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better

I think one of the problems here is that there is no consistent requirements or figure of merit for performance. You've argued against changes because of A) perceived impact to front-end I/O latency, B) writeback rate at idle, C) peak instantaneous writeback rate, D) time to writeback the entire

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On Thu, Oct 5, 2017 at 3:07 PM, Jens Axboe wrote: > Yes, it's not impossible, I just usually prefer not to. For this case, I > just setup a for-4.15/timer, that is the current block branch with -rc3 > pulled in. I applied the two patches for floppy and amiflop, I'm > assuming

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On 10/05/2017 03:53 PM, Thomas Gleixner wrote: > Jens, > > On Thu, 5 Oct 2017, Jens Axboe wrote: >> On 10/05/2017 01:23 PM, Thomas Gleixner wrote: >>> Come on. You know very well that a prerequisite for global changes which is >>> not yet used in Linus tree can get merged post merge windew in

[PATCH] blk-stat: delete useless code

Fix two issues: - the per-cpu stat flush is unnecessary, nobody uses per-cpu stat except sum it to global stat. We can do the calculation there. The flush just wastes cpu time. - some fields are signed int/s64. I don't see the point. Cc: Omar Sandoval Signed-off-by: Shaohua

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

Jens, On Thu, 5 Oct 2017, Jens Axboe wrote: > On 10/05/2017 01:23 PM, Thomas Gleixner wrote: > > Come on. You know very well that a prerequisite for global changes which is > > not yet used in Linus tree can get merged post merge windew in order to > > avoid massive inter maintainer tree

Re: [PATCH, resend] block: remove QUEUE_FLAG_STACKABLE

On Thu, Oct 05 2017 at 3:22pm -0400, Christoph Hellwig wrote: > We already have a queue_is_rq_based helper to check if a request_queue > is request based, so we can remove the flag for it. > > Signed-off-by: Christoph Hellwig Acked-by: Mike Snitzer

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On 10/05/2017 01:41 PM, Jens Axboe wrote: > On 10/05/2017 01:23 PM, Thomas Gleixner wrote: >> On Thu, 5 Oct 2017, Jens Axboe wrote: >>> On 10/05/2017 11:49 AM, Kees Cook wrote: Yes, totally true. tglx and I ended up meeting face-to-face at the Kernel Recipes conference and we solved some

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On 10/05/2017 01:23 PM, Thomas Gleixner wrote: > On Thu, 5 Oct 2017, Jens Axboe wrote: >> On 10/05/2017 11:49 AM, Kees Cook wrote: >>> Yes, totally true. tglx and I ended up meeting face-to-face at the >>> Kernel Recipes conference and we solved some outstanding design issues >>> with the

Re: [PATCH v2 2/2] block: cope with WRITE ZEROES failing in blkdev_issue_zeroout()

On Thu, Oct 5, 2017 at 7:13 PM, Christoph Hellwig wrote: > On Wed, Oct 04, 2017 at 05:03:16PM +0200, Ilya Dryomov wrote: >> sd_config_write_same() ignores ->max_ws_blocks == 0 and resets it to >> permit trying WRITE SAME on older SCSI devices, unless ->no_write_same >> is set.

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On Thu, 5 Oct 2017, Jens Axboe wrote: > On 10/05/2017 11:49 AM, Kees Cook wrote: > > Yes, totally true. tglx and I ended up meeting face-to-face at the > > Kernel Recipes conference and we solved some outstanding design issues > > with the conversion. The timing meant the new API went into -rc3, >

[PATCH, resend] block: remove QUEUE_FLAG_STACKABLE

We already have a queue_is_rq_based helper to check if a request_queue is request based, so we can remove the flag for it. Signed-off-by: Christoph Hellwig --- block/blk-mq-debugfs.c | 1 - block/elevator.c | 2 +- drivers/md/dm-rq.c | 2 +- drivers/md/dm-table.c | 15

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On 10/05/2017 12:49 PM, Kees Cook wrote: > On Thu, Oct 5, 2017 at 11:26 AM, Jens Axboe wrote: >> Honestly, I think the change should have waited for 4.15 in that case. >> Why the rush? It wasn't ready for the merge window. > > My understanding from my discussion with tglx was

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On Thu, Oct 5, 2017 at 11:26 AM, Jens Axboe wrote: > Honestly, I think the change should have waited for 4.15 in that case. > Why the rush? It wasn't ready for the merge window. My understanding from my discussion with tglx was that if the API change waiting for 4.15, then the

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On 10/05/2017 11:49 AM, Kees Cook wrote: > On Thu, Oct 5, 2017 at 7:56 AM, Jens Axboe wrote: >> On 10/04/2017 06:49 PM, Kees Cook wrote: >>> In preparation for unconditionally passing the struct timer_list pointer to >>> all timer callbacks, switch to using the new timer_setup()

Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better

On 2017/10/6 上午1:53, Michael Lyle wrote: > On Thu, Oct 5, 2017 at 10:38 AM, Coly Li wrote: >> [snip] >> In this test, without bio reorder patches, writeback throughput is >> much faster, you may see the write request number and request merge >> number are also much faster then bio

[PATCH] block: remove unnecessary NULL checks in bioset_integrity_free()

mempool_destroy() already checks for a NULL value being passed in, this eliminates duplicate checks. This was caught by running make coccicheck M=block/ on linus' tree on commit 77ede3a014a32746002f7889211f0cecf4803163 (current head as of this patch). Signed-off-by: Tim Hansen

Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better

On Thu, Oct 5, 2017 at 10:38 AM, Coly Li wrote: > [snip] > In this test, without bio reorder patches, writeback throughput is > much faster, you may see the write request number and request merge > number are also much faster then bio reorder patches. After around 10 > minutes

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On Thu, Oct 5, 2017 at 7:56 AM, Jens Axboe wrote: > On 10/04/2017 06:49 PM, Kees Cook wrote: >> In preparation for unconditionally passing the struct timer_list pointer to >> all timer callbacks, switch to using the new timer_setup() and from_timer() >> to pass the timer pointer

Re: [PATCH 4/5] bcache: writeback: collapse contiguous IO better

On 2017/10/5 上午7:54, Michael Lyle wrote: > Coly--- > > Thanks for running these tests. > Hi Mike, You provided very detailed information for the PI controller patch, make me understand it better. As a return, I spend several days to test your bio reorder patches, you are deserved :-) > The

Re: [RFC 2/2] blockcg: export latency info for each cgroup

Hello, Shaohua. On Thu, Oct 05, 2017 at 09:45:05AM -0700, Shaohua Li wrote: > Looks that is similar to how io.stat exposes bytes/ios. It does the > propagation at the time when user read the status file. However, doing the > same > for latency is meaningless, we shouldn't accumulate latency for

Re: [PATCH v2 0/9] Nowait support for stacked block devices

On Wed, Oct 04, 2017 at 08:55:02AM -0500, Goldwyn Rodrigues wrote: > This is a continuation of the nowait support which was incorporated > a while back. We introduced REQ_NOWAIT which would return immediately > if the call would block at the block layer. Request based-devices > do not wait.

Re: [Question] on blk_mq_map_queues()

On 05/10/2017 17:27, Christoph Hellwig wrote: On Thu, Oct 05, 2017 at 05:06:54PM +0100, John Garry wrote: It's a HiSilicon hip07 (D05) platform. For this platform, the integrated SAS controller is a platform device. This controller supports 16 hw queues. That's v1 or v2 in

Re: [PATCH v2 2/2] block: cope with WRITE ZEROES failing in blkdev_issue_zeroout()

On Wed, Oct 04, 2017 at 05:03:16PM +0200, Ilya Dryomov wrote: > sd_config_write_same() ignores ->max_ws_blocks == 0 and resets it to > permit trying WRITE SAME on older SCSI devices, unless ->no_write_same > is set. Because REQ_OP_WRITE_ZEROES is implemented in terms of WRITE > SAME,

Re: [PATCH v2 1/2] block: factor out __blkdev_issue_zero_pages()

Looks good, Reviewed-by: Christoph Hellwig

Re: [PATCH 4/9] qla2xxx: don't break the bsg-lib abstractions

> On Oct 3, 2017, at 3:48 AM, Christoph Hellwig wrote: > > Always use bsg_job->reply instead of scsi_req(bsg_job->req)->sense), as > they always point to the same memory. > > Never set scsi_req(bsg_job->req)->result and we'll set that value through > bsg_job_done. > >

Re: [GIT PULL] nvme fixes for Linux 4.14-rc4

On 10/05/2017 10:36 AM, Christoph Hellwig wrote: > A trivial one-liner from Martin to fix the visible of the uuid attr, > and another one (originally from Abhishek Shah, rewritten by me) to > fix the CMB addresses passed back to the controller in case of a system > that remaps BAR addresses

Re: [RFC 2/2] blockcg: export latency info for each cgroup

On Wed, Oct 04, 2017 at 11:04:39AM -0700, Tejun Heo wrote: > Hello, > > On Wed, Oct 04, 2017 at 10:41:20AM -0700, Shaohua Li wrote: > > Export the latency info to user. The latency is a good sign to indicate > > if IO is congested or not. User can use the info to make decisions like > > adjust

Re: Circular locking dependency with pblk

> On 5 Oct 2017, at 18.24, Jens Axboe wrote: > > On 10/05/2017 04:53 AM, Javier González wrote: >> Hi, >> >> lockdep is reporting a circular dependency when using XFS and pblk, >> which I am a bit confused about. >> >> This happens when XFS sends a number of nested reads and

[GIT PULL] nvme fixes for Linux 4.14-rc4

A trivial one-liner from Martin to fix the visible of the uuid attr, and another one (originally from Abhishek Shah, rewritten by me) to fix the CMB addresses passed back to the controller in case of a system that remaps BAR addresses between host and device. The following changes since commit

Re: false positive lockdep splat with loop device

Does the patch below fix the warning for you? -- >From 28aae7104425433d39e6142adcd5b88dc5b0ad5f Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Thu, 5 Oct 2017 18:31:02 +0200 Subject: block: use DECLARE_COMPLETION_ONSTACK in submit_bio_wait This way we get our lockdep

Re: [Question] on blk_mq_map_queues()

On Thu, Oct 05, 2017 at 05:06:54PM +0100, John Garry wrote: > It's a HiSilicon hip07 (D05) platform. For this platform, the integrated > SAS controller is a platform device. This controller supports 16 hw queues. That's v1 or v2 in drivers/scsi/hisi_sas? Seems like you need to implement the

Re: Circular locking dependency with pblk

On 10/05/2017 04:53 AM, Javier González wrote: > Hi, > > lockdep is reporting a circular dependency when using XFS and pblk, > which I am a bit confused about. > > This happens when XFS sends a number of nested reads and (at least) one > of them hits partially pblk's cache. In this case, pblk

Re: [Question] on blk_mq_map_queues()

On 05/10/2017 16:59, Christoph Hellwig wrote: On Thu, Oct 05, 2017 at 02:28:43PM +0100, John Garry wrote: I know that we can add our own per-driver mapping function to solve, but I would expect that that generic mapper would cover a generic platform. Why aren't you using

Re: [Question] on blk_mq_map_queues()

On Thu, Oct 05, 2017 at 02:28:43PM +0100, John Garry wrote: > I know that we can add our own per-driver mapping function to solve, but I > would expect that that generic mapper would cover a generic platform. Why aren't you using blk_mq_pci_map_queues? What kind of hardware are we talking

Re: [PATCH] block/laptop_mode: Convert timers to use timer_setup()

On 10/04/2017 06:49 PM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Jens Axboe > Cc: Michal Hocko

Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support

On Thursday, October 05, 2017 02:00:48 PM Bartlomiej Zolnierkiewicz wrote: > > > > I am trying to wrap my head around this large patch. The size makes it > > > > hard but I am doing my best. > > > > > > I also think that this patch should be split on two patches. The 1st one > > > introducing

[Question] on blk_mq_map_queues()

Hi All, I have a question on the core-to-hw queue mapping in blk_mq_map_queues(). In looking at the latest version, we map the first $nr_queues cores to separate queues, and then map sibling threaded-cores to the same queue. First off, I am just curious why we always map the first batch of

Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support

On 5 October 2017 at 12:55, Bartlomiej Zolnierkiewicz wrote: > On Wednesday, October 04, 2017 11:48:27 AM Ulf Hansson wrote: >> [...] >> >> >> MQ code that doesn't perform and therefore we cannot switch seamlessly >> >> to MQ. >> > >> > I think that switching seamlessly

Re: [PATCH V9 13/15] mmc: block: Add CQE and blk-mq support

On Wednesday, October 04, 2017 11:48:27 AM Ulf Hansson wrote: > [...] > > >> MQ code that doesn't perform and therefore we cannot switch seamlessly > >> to MQ. > > > > I think that switching seamlessly to blk-mq in short/medium-term > > is not possible (SCSI tried and failed to do so). The

Circular locking dependency with pblk

Hi, lockdep is reporting a circular dependency when using XFS and pblk, which I am a bit confused about. This happens when XFS sends a number of nested reads and (at least) one of them hits partially pblk's cache. In this case, pblk will retrieve the cached lbas and form a new bio, which is

[PATCH V10 13/15] mmc: block: Add CQE and blk-mq support

Add CQE support to the block driver, including: - optionally using DCMD for flush requests - "manually" issuing discard requests - issuing read / write requests to the CQE - supporting block-layer timeouts - handling recovery - supporting re-tuning CQE offers 25% - 50%

[PATCH] lightnvm: pblk: remove spinlock when freeing line metadata

From: Hans Holmberg Lockdep complains about being in atomic context while freeing line metadata - and rightly so as we take a spinlock and end up calling vfree that might sleep(in pblk_mfree). There is no need for holding the line manager free_lock while freeing line