From: Tang Junhui
In GC thread, we record the latest GC key in gc_done, which is expected
to be used for incremental GC, but in currently code, we didn't realize
it. When GC runs, front side IO would be blocked until the GC over, it
would be a long time if there is a lot of btree nodes.
This pat
Hi maintainers and folks,
Some patches of this patch set have been sent before, they are not merged
yet, and I add two new patches to solve some issues I found while testing.
since They are interdependent, so I make a patch set and resend them.
[PATCH 1/4] bcache: finish incremental GC
[PATCH 2/4
From: Tang Junhui
Since no new bucket can be allocated during GC, and front side I/Os would
run out of all the buckets, so notify allocator to pack the free_inc queue
full of buckets before GC, then we could have enough buckets for front side
I/Os during GC period.
The main idea of this patch is
From: Tang Junhui
This patch base on "[PATCH] bcache: finish incremental GC".
Since incremental GC would stop 100ms when front side I/O comes, so when
there are many btree nodes, if GC only processes constant (100) nodes each
time, GC would last a long time, and the front I/Os would run out of t
From: Tang Junhui
I attached several backend devices in the same cache set, and produced lots
of dirty data by running small rand I/O writes in a long time, then I
continue run I/O in the others cached devices, and stopped a cached device,
after a mean while, I register the stopped device again,
On Sun, 2018-04-15 at 19:35 -0600, Tim Walker wrote:
> I also believe the dual-actuator, or any significant HDD parallelism,
> would map well onto an NVMe target, or NVMe-oF behind nvmet. Maybe a
> lightweight virtual NVMe controller that would efficiently present the
> HDD logs/mode pages/etc via
On Mon, Apr 9, 2018 at 10:02 AM, Douglas Gilbert wrote:
>
> On 2018-04-09 02:17 AM, Hannes Reinecke wrote:
>>
>> On 04/09/2018 04:08 AM, Tim Walker wrote:
>>>
>>> On Fri, Apr 6, 2018 at 11:09 AM, Douglas Gilbert
>>> wrote:
On 2018-04-06 02:42 AM, Christoph Hellwig wrote:
>
>>>
On Sun, Apr 15, 2018 at 06:31:44PM +0200, Martin Steigerwald wrote:
> Hi Ming.
>
> Ming Lei - 15.04.18, 17:43:
> > Hi Jens,
> >
> > This two patches fixes the recently discussed race between completion
> > and BLK_EH_RESET_TIMER.
> >
> > Israel & Martin, this one is a simpler fix on this issue a
On Sun, Apr 15, 2018 at 04:59:37PM +0200, Christoph Hellwig wrote:
> This function is only used by built-in code.
>
> Reviewed-by: Christoph Hellwig
Signed-off-by:
Sam
Hi Ming.
Ming Lei - 15.04.18, 17:43:
> Hi Jens,
>
> This two patches fixes the recently discussed race between completion
> and BLK_EH_RESET_TIMER.
>
> Israel & Martin, this one is a simpler fix on this issue and can
> cover the potencial hang of MQ_RQ_COMPLETE_IN_TIMEOUT request, could
> you te
When backing device is offline, memory object pointed by dc->bdev might be
released in some condititions. I have bug report that bdevname() triggers
a NULL pointer deference panic inside bch_cached_dev_error(), where
dc->bdev is NULL.
This patch adds char backing_dev_name[BDEVNAME_SIZE] in struct
Firstly blk_mq_timeout_work() is always run exclusivley for each queue.
Secondly if .timeout() returns BLK_EH_RESET_TIMER or BLK_EH_HANDLED,
the flag of RQF_MQ_TIMEOUT_EXPIRED will be cleared for this request,
because the request will be requeued or freed for BLK_EH_HANDLED, and
for BLK_EH_RESET_T
The normal request completion can be done before or during handling
BLK_EH_RESET_TIMER, and this race may cause the request to never
be completed since driver's .timeout() may always return
BLK_EH_RESET_TIMER.
This issue can't be fixed completely by driver, since the normal
completion can be done
Hi Jens,
This two patches fixes the recently discussed race between completion
and BLK_EH_RESET_TIMER.
Israel & Martin, this one is a simpler fix on this issue and can
cover the potencial hang of MQ_RQ_COMPLETE_IN_TIMEOUT request, could
you test V4 and see if your issue can be fixed?
Thanks,
V4
On Sat, Apr 14, 2018 at 03:22:07PM +, Bart Van Assche wrote:
> On Fri, 2018-04-13 at 21:06 -0600, Jens Axboe wrote:
> > I like this approach since it keeps the cost outside of the fast
> > path. And it's fine to reuse the queue lock for this, instead of
> > adding a special lock for something w
This way we have one central definition of it, and user can select it as
needed.
Signed-off-by: Christoph Hellwig
---
arch/alpha/Kconfig | 4 +---
arch/arm/Kconfig| 3 ---
arch/arm64/Kconfig | 4 +---
arch/hexagon/Kconfig| 4 +---
arch/ia64/K
swiotlb now selects the DMA_DIRECT_OPS config symbol, so this will
always be true.
Signed-off-by: Christoph Hellwig
---
lib/swiotlb.c | 4
1 file changed, 4 deletions(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 47aeb04c1997..07f260319b82 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb
Define this symbol if the architecture either uses 64-bit pointers or the
PHYS_ADDR_T_64BIT is set. This covers 95% of the old arch magic. We only
need an additional select for Xen on ARM (why anyway?), and we now always
set ARCH_DMA_ADDR_T_64BIT on mips boards with 64-bit physical addressing
ins
Instead select the PHYS_ADDR_T_64BIT for 32-bit architectures that need a
64-bit phys_addr_t type directly.
Signed-off-by: Christoph Hellwig
---
arch/arc/Kconfig | 4 +---
arch/arm/kernel/setup.c| 2 +-
arch/arm/mm/Kconfig| 4 +---
arc
This way we have one central definition of it, and user can select it as
needed. Note that we also add a second ARCH_HAS_SWIOTLB symbol to
indicate the architecture supports swiotlb at all, so that we can still
make the usage optional for a few architectures that want this feature
to be user selec
swiotlb is only used as a library of helper for xen-swiotlb if Xen support
is enabled on arm, so don't build it by default.
Signed-off-by: Christoph Hellwig
---
arch/arm/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index aa1c18
This symbol is now always identical to CONFIG_ARCH_DMA_ADDR_T_64BIT, so
remove it.
Signed-off-by: Christoph Hellwig
---
drivers/pci/Kconfig | 4
drivers/pci/bus.c | 4 ++--
include/linux/pci.h | 2 +-
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/Kconfig b/dri
This function is only used by built-in code.
Reviewed-by: Christoph Hellwig
---
lib/iommu-helper.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index 23633c0fda4a..ded1703e7e64 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -3,7 +3,6 @
This way we have one central definition of it, and user can select it as
needed. Note that we now also always select it when CONFIG_DMA_API_DEBUG
is select, which fixes some incorrect checks in a few network drivers.
Signed-off-by: Christoph Hellwig
---
arch/alpha/Kconfig | 4 +---
arc
This way we have one central definition of it, and user can select it as
needed.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/Kconfig | 4 +---
arch/s390/Kconfig| 5 ++---
arch/sparc/Kconfig | 5 +
arch/x86/Kconfig | 6 ++
lib/Kconfig | 3 +++
5 files changed, 9 i
This avoids selecting IOMMU_HELPER just for this function. And we only
use it once or twice in normal builds so this often even is a size
reduction.
Signed-off-by: Christoph Hellwig
---
arch/alpha/Kconfig | 3 ---
arch/arm/Kconfig| 3 ---
arch/arm64/Kconfig
This code is only used by sparc, and all new iommu drivers should use the
drivers/iommu/ framework. Also remove the unused exports.
Signed-off-by: Christoph Hellwig
---
{include/linux => arch/sparc/include/asm}/iommu-common.h | 0
arch/sparc/include/asm/iommu_64.h| 2 +-
Hi all,
this seris aims for a single defintion of the Kconfig symbol. To get
there various cleanups, mostly about config symbols are included as well.
Hi,
On 4/12/2018 4:35 PM, t...@kernel.org wrote:
Hello, Israel.
On Thu, Apr 12, 2018 at 11:59:11AM +0300, Israel Rukshin wrote:
On 4/12/2018 12:31 AM, t...@kernel.org wrote:
Hey, again.
On Wed, Apr 11, 2018 at 10:07:33AM -0700, t...@kernel.org wrote:
Hello, Israel.
On Wed, Apr 11, 2018 at
On 14/04/18 20:52, Jens Axboe wrote:
On 4/14/18 1:46 PM, Alan Jenkins wrote:
On 13/04/18 09:31, Johannes Thumshirn wrote:
Hi Alan,
On Thu, 2018-04-12 at 19:11 +0100, Alan Jenkins wrote:
# dd if=/dev/sda of=/dev/null iflag=direct & \
while killall -SIGUSR1 dd; do sleep 0.1; done & \
ec
On Fri, Apr 13, 2018 at 03:07:18PM +0200, Steffen Maier wrote:
> Complements v2.6.31 commit 55782138e47d ("tracing/events: convert block
> trace points to TRACE_EVENT()") to be equivalent to traditional blktrace
> output. Also this allows event filtering to not always get all (un)plug
> events.
>
31 matches
Mail list logo
