[PATCH] [PATCH V2] bcache: fix wrong cache_misses statistics

From: "tang.junhui" Currently, Cache missed IOs are identified by s->cache_miss, but actually, there are many situations that missed IOs are not assigned a value for s->cache_miss in cached_dev_cache_miss(), for example, a bypassed IO (s->iop.bypass = 1), or the cache_bio

Re: Re: [PATCH 11/19] bcache: Subtract dirty sectors of thin flash from cache_sectors in calculating writeback rate

From: Tang Junhui Hello Eric > > I discussed with Tang offline, this patch is correct. But the patch > > commit log should be improved. Now I help to work on it, should be done > > quite soon. > > Has an updated commit log been made? I've not seen this in the commit >

Re: Re: [PATCH 04/19] bcache: fix wrong cache_misses statistics

From: Tang Junhui Hello Eric > > I'm waiting to queue this patch pending your response to Coly. Can you > > update the message send a v2? > > Hi Tang, > > Can you to an update message and send this in so we can get the cache miss > metrics corrected? Sorry, I

Re: [PATCHv4] bcache: only permit to recovery read error when cache device is clean

On Fri, Oct 27, 2017 at 4:31 PM, Eric Wheeler wrote: >> Seems like something that's a lot of effort for little gain. It'll >> only help when A) everything you need isn't dirty, and > > Indeed! > >> B) all the associated btree nodes are in memory. > > Is the dirty key

Re: [PATCHv4] bcache: only permit to recovery read error when cache device is clean

On Fri, 27 Oct 2017, Michael Lyle wrote: > On Fri, Oct 27, 2017 at 2:13 PM, Eric Wheeler > wrote: > [snip] > >> > Can KEY_DIRTY facilitate this? > >> > >> Don't we only have the metadata to know if the key is dirty on the > >> cache if we have the cache device? ;) > >

Re: [PATCHv4] bcache: only permit to recovery read error when cache device is clean

On Fri, Oct 27, 2017 at 2:13 PM, Eric Wheeler wrote: [snip] >> > Can KEY_DIRTY facilitate this? >> >> Don't we only have the metadata to know if the key is dirty on the >> cache if we have the cache device? ;) > > Certainly if this is for removal or a missing cache

Re: [PATCH] [PATCH v2] bcache: fix calling ida_simple_remove() with incorrect minor

On Fri, 27 Oct 2017, Michael Lyle wrote: > Eric-- > > On Fri, Oct 27, 2017 at 12:17 PM, Eric Wheeler > wrote: > > Hi Tang, > > > > This is an important bugfix since v4.10, can you get a clean patch sent to > > the list? > > > > Michael, if Tang can get this in on

Re: [PATCHv4] bcache: only permit to recovery read error when cache device is clean

On Fri, 27 Oct 2017, Michael Lyle wrote: > On Fri, Oct 27, 2017 at 12:57 PM, Eric Wheeler > wrote: > > Can this be relaxed to only error when the key failing to read is dirty? > > The liklihood of a 100% clean cache in writeback on a busy system seems > > unlikely. > >

Re: [PATCHv4] bcache: only permit to recovery read error when cache device is clean

On Tue, 17 Oct 2017, Coly Li wrote: > When bcache does read I/Os, for example in writeback or writethrough mode, > if a read request on cache device is failed, bcache will try to recovery > the request by reading from cached device. If the data on cached device is > not synced with cache device,

Re: [PATCH 12/19] bcache: update bucket_in_use periodically

On Fri, 27 Oct 2017, Eric Wheeler wrote: > On Thu, 13 Jul 2017, Coly Li wrote: > > > On 2017/7/13 下午12:13, Eric Wheeler wrote: > > > On Tue, 11 Jul 2017, Coly Li wrote: > > > > > >> On 2017/7/11 下午1:39, tang.jun...@zte.com.cn wrote: > > >>> Compared to bucket depletion, resulting in hanging

Re: [PATCH] [PATCH v2] bcache: fix calling ida_simple_remove() with incorrect minor

On Thu, 13 Jul 2017, Eric Wheeler wrote: > Tang, > > Please resend. This patch seems to be malformed. Hi Tang, This is an important bugfix since v4.10, can you get a clean patch sent to the list? Michael, if Tang can get this in on time, can this squeeze this into v4.14 before the rc's run

Re: [PATCH 15/19] bcache: fix issue of writeback rate at minimum 1 key per second

[+cc Michael Lyle] On Fri, 27 Oct 2017, Eric Wheeler wrote: > On Sun, 16 Jul 2017, Coly Li wrote: > > > On 2017/7/1 上午4:43, bca...@lists.ewheeler.net wrote: > > > From: Tang Junhui > > > > > > When there is not enough dirty data in writeback cache, > > > writeback

Re: [PATCH 12/19] bcache: update bucket_in_use periodically

On Thu, 13 Jul 2017, Coly Li wrote: > On 2017/7/13 下午12:13, Eric Wheeler wrote: > > On Tue, 11 Jul 2017, Coly Li wrote: > > > >> On 2017/7/11 下午1:39, tang.jun...@zte.com.cn wrote: > >>> Compared to bucket depletion, resulting in hanging dead, > >>> It is worthy to consumes a little time to

Re: [PATCH 04/19] bcache: fix wrong cache_misses statistics

On Thu, 13 Jul 2017, Eric Wheeler wrote: > On Sun, 2 Jul 2017, Coly Li wrote: > > > On 2017/7/1 上午4:42, bca...@lists.ewheeler.net wrote: > > > From: Tang Junhui > > > > > > Some missed IOs are not counted into cache_misses, this patch fix this > > > issue. > > > >

Re: [PATCH 11/19] bcache: Subtract dirty sectors of thin flash from cache_sectors in calculating writeback rate

On Thu, 13 Jul 2017, Coly Li wrote: > On 2017/7/13 下午12:12, Eric Wheeler wrote: > > On Tue, 11 Jul 2017, tang.jun...@zte.com.cn wrote: > > > >>> Based on the above implementation, non-dirty space from flash only > >>> bcache device will mislead writeback rate calculation too. So I suggest > >>>

Re: [PATCH 00/12 v4] multiqueue for MMC/SD

On Fri, Oct 27, 2017 at 2:59 PM, Adrian Hunter wrote: > On 27/10/17 14:25, Linus Walleij wrote: >> It is indeed tough to juggle this with the pressure to "upstream >> first" the BFQ scheduler policy that we are working on in Linaro >> to increase interactivity. We need

Re: [PATCH v4] virtio_blk: Fix an SG_IO regression

On 10/27/2017 12:39 AM, Christoph Hellwig wrote: > On Thu, Oct 26, 2017 at 12:10:15PM +0200, Bart Van Assche wrote: >> Avoid that submitting an SG_IO ioctl triggers a kernel oops that >> is preceded by: >> >> usercopy: kernel memory overwrite attempt detected to (null) () (6 >> bytes) >> kernel

Re: [PATCH 11/12 v4] mmc: block: issue requests in massive parallel

On 26 October 2017 at 14:57, Linus Walleij wrote: > This makes a crucial change to the issueing mechanism for the > MMC requests: > > Before commit "mmc: core: move the asynchronous post-processing" > some parallelism on the read/write requests was achieved by >

Re: [GIT PULL] one nvme fix for 4.14

On 10/27/2017 12:23 AM, Christoph Hellwig wrote: > The following changes since commit f04b9cc87b5fc466b1b7231ba7b078e885956c5b: > > nvme-rdma: Fix error status return in tagset allocation failure (2017-10-19 > 17:13:51 +0200) > > are available in the git repository at: > >

Re: [PATCH V12 2/5] mmc: block: Add blk-mq support

>>> >>> -#define CMD_ERRORS \ >>> - (R1_OUT_OF_RANGE | /* Command argument out of range */ \ >>> -R1_ADDRESS_ERROR | /* Misaligned address */\ >>> +#define CMD_ERRORS_EXCL_OOR

Re: [PATCH 00/12 v4] multiqueue for MMC/SD

On 27/10/17 14:25, Linus Walleij wrote: > On Thu, Oct 26, 2017 at 9:27 PM, Hunter, Adrian > wrote: >> On Thu, Oct 26, 2017 at 3:34 PM, Adrian Hunter > >>> What I mean is that the CQE code will likely look better on top of these >>>

Re: [PATCH V12 2/5] mmc: block: Add blk-mq support

On 27/10/17 12:23, Ulf Hansson wrote: > On 24 October 2017 at 10:40, Adrian Hunter wrote: >> Define and use a blk-mq queue. Discards and flushes are processed >> synchronously, but reads and writes asynchronously. In order to support >> slow DMA unmapping, DMA unmapping

Re: [PATCH 00/12 v4] multiqueue for MMC/SD

On Thu, Oct 26, 2017 at 9:27 PM, Hunter, Adrian wrote: > On Thu, Oct 26, 2017 at 3:34 PM, Adrian Hunter >> What I mean is that the CQE code will likely look better on top of these >> refactorings. >> >> But as I say it is a matter of taste. I

Re: [PATCH V12 2/5] mmc: block: Add blk-mq support

On 24 October 2017 at 10:40, Adrian Hunter wrote: > Define and use a blk-mq queue. Discards and flushes are processed > synchronously, but reads and writes asynchronously. In order to support > slow DMA unmapping, DMA unmapping is not done until after the next request >

Re: [PATCH v4] virtio_blk: Fix an SG_IO regression

On Thu, Oct 26, 2017 at 12:10:15PM +0200, Bart Van Assche wrote: > Avoid that submitting an SG_IO ioctl triggers a kernel oops that > is preceded by: > > usercopy: kernel memory overwrite attempt detected to (null) () (6 > bytes) > kernel BUG at mm/usercopy.c:72! > > Reported-by: Dann Frazier

[GIT PULL] one nvme fix for 4.14

The following changes since commit f04b9cc87b5fc466b1b7231ba7b078e885956c5b: nvme-rdma: Fix error status return in tagset allocation failure (2017-10-19 17:13:51 +0200) are available in the git repository at: git://git.infradead.org/nvme.git nvme-4.14 for you to fetch changes up to