Re: [PATCH 0/3] block: blk_interposer - Block Layer Interposer

Hi Folks, On 12/12/20 12:56 AM, Hannes Reinecke wrote: > On 12/11/20 5:33 PM, Jens Axboe wrote: >> On 12/11/20 9:30 AM, Mike Snitzer wrote: >>> While I still think there needs to be a proper _upstream_ consumer of >>> blk_interposer as a condition of it going in.. I'll let others make the >>>

Re: [PATCH v3] dm crypt: add flags to optionally bypass dm-crypt workqueues

_type_t type, > DMEMIT(" same_cpu_crypt"); > if (test_bit(DM_CRYPT_NO_OFFLOAD, >flags)) > DMEMIT(" submit_from_crypt_cpus"); > + if (test_bit(DM_CRYPT_NO_READ_WORKQUEUE, >flags)) > + DMEMIT(" no_read_workqueue"); > + if (test_bit(DM_CRYPT_NO_WRITE_WORKQUEUE, >flags)) > + DMEMIT(" no_write_workqueue"); > if (cc->on_disk_tag_size) > DMEMIT(" integrity:%u:%s", > cc->on_disk_tag_size, cc->cipher_auth); > if (cc->sector_size != (1 << SECTOR_SHIFT)) > @@ -3320,7 +3354,7 @@ static void crypt_io_hints(struct dm_target *ti, struct > queue_limits *limits) > > static struct target_type crypt_target = { > .name = "crypt", > - .version = {1, 21, 0}, > + .version = {1, 22, 0}, > .module = THIS_MODULE, > .ctr= crypt_ctr, > .dtr= crypt_dtr, > This patch looks good to me, I tested with null_blk and got similar improvement. Thanks! Reviewed-by: Bob Liu

Re: [dm-devel] [PATCH v2] dm crypt: add flags to optionally bypass dm-crypt workqueues

Hi Ignat, On 6/27/20 5:03 AM, Ignat Korchagin wrote: > This is a follow up from [1]. Consider the following script: > > sudo modprobe brd rd_nr=1 rd_size=4194304 > Did you test null_blk device? I didn't get result as expected using null_blk. 1. # fio --filename=/dev/nullb0

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

On 6/29/20 8:37 AM, Lai Jiangshan wrote: > On Mon, Jun 29, 2020 at 8:13 AM Bob Liu wrote: >> >> On 6/28/20 11:54 PM, Lai Jiangshan wrote: >>> On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote: >>>> >>>> Current code always set 'Unbound && max_a

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

On 6/29/20 8:37 AM, Lai Jiangshan wrote: > On Mon, Jun 29, 2020 at 8:13 AM Bob Liu wrote: >> >> On 6/28/20 11:54 PM, Lai Jiangshan wrote: >>> On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote: >>>> >>>> Current code always set 'Unbound && max_a

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

On 6/28/20 11:54 PM, Lai Jiangshan wrote: > On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote: >> >> Current code always set 'Unbound && max_active == 1' workqueues to ordered >> implicitly, while this may be not an expected behaviour for some use cases. >> &g

Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

ping.. On 6/11/20 6:07 PM, Bob Liu wrote: > Current code always set 'Unbound && max_active == 1' workqueues to ordered > implicitly, while this may be not an expected behaviour for some use cases. > > E.g some scsi and iscsi workqueues(unbound && max_active = 1) wa

[PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly

ut their cpumask can't be changed because WQ_ORDERED is set implicitly. This patch adds a flag __WQ_ORDERED_DISABLE and also create_singlethread_workqueue_noorder() to offer an new option. Signed-off-by: Bob Liu --- include/linux/workqueue.h | 4 kernel/workqueue.c| 4 +++- 2

[PATCH 2/2] scsi: register sysfs for scsi/iscsi workqueues

This patch enable setting cpu affinity through "cpumask" for below scsi/iscsi workqueues, so as to get better isolation. - scsi_wq_* - scsi_tmf_* - iscsi_q_xx - iscsi_eh Signed-off-by: Bob Liu --- drivers/scsi/hosts.c| 4 ++-- drivers/scsi/libiscsi.c | 2 +

Re: [PATCH 1/1] blk-mq: get ctx in order to handle BLK_MQ_S_INACTIVE in blk_mq_get_tag()

.q = rq->q, > + .ctx = rq->mq_ctx, > .hctx = rq->mq_hctx, > .flags = BLK_MQ_REQ_NOWAIT, > .cmd_flags = rq->cmd_flags, > Nice catch! Reviewed-by: Bob Liu

Re: [PATCH] block/bio-integrity: don't free 'buf' if bio_integrity_add_page() failed

KERN_ERR "could not attach integrity payload\n"); > - kfree(buf); > status = BLK_STS_RESOURCE; > goto err_end_io; > } > Looks good to me. Reviewed-by: Bob Liu

Re: [RFC PATCH v1 0/7] Block/XFS: Support alternative mirror device retry

On 11/28/18 3:45 PM, Christoph Hellwig wrote: > On Wed, Nov 28, 2018 at 04:33:03PM +1100, Dave Chinner wrote: >> - how does propagation through stacked layers work? > > The only way it works is by each layering driving it. Thus my > recommendation above bilding on your earlier one to use an

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 11:38, Lu Baolu wrote: > Hi, > > On 12/14/2017 11:10 AM, Bob Liu wrote: >> On 2017/12/14 9:02, Lu Baolu wrote: >>>> From: Huang Ying <ying.hu...@intel.com> >>>> >>>> Shared Virtual Memory (SVM) allows a kernel memory map

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 11:38, Lu Baolu wrote: > Hi, > > On 12/14/2017 11:10 AM, Bob Liu wrote: >> On 2017/12/14 9:02, Lu Baolu wrote: >>>> From: Huang Ying >>>> >>>> Shared Virtual Memory (SVM) allows a kernel memory mapping to be >>>> s

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 9:02, Lu Baolu wrote: > From: Huang Ying > > Shared Virtual Memory (SVM) allows a kernel memory mapping to be > shared between CPU and and a device which requested a supervisor > PASID. Both devices and IOMMU units have TLBs that cache entries > from CPU's

Re: [PATCH 1/2] mm: Add kernel MMU notifier to manage IOTLB/DEVTLB

On 2017/12/14 9:02, Lu Baolu wrote: > From: Huang Ying > > Shared Virtual Memory (SVM) allows a kernel memory mapping to be > shared between CPU and and a device which requested a supervisor > PASID. Both devices and IOMMU units have TLBs that cache entries > from CPU's page tables. We need to

Re: [RFC PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry

d access > these already freed memory through tlb entries. > > This patch gather each vma instead of gathering full vm space, > tlb->fullmm is not true. The behavior of oom reaper become similar > to munmapping before do_exit, which should be safe for all archs. > > Signed-off-b

Re: [RFC PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry

eed memory through tlb entries. > > This patch gather each vma instead of gathering full vm space, > tlb->fullmm is not true. The behavior of oom reaper become similar > to munmapping before do_exit, which should be safe for all archs. > > Signed-off-by: Wang Nan > Cc: Bob

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On 2017/10/12 17:50, Liu, Yi L wrote: > > >> -Original Message----- >> From: Bob Liu [mailto:liub...@huawei.com] >> Sent: Thursday, October 12, 2017 5:39 PM >> To: Jean-Philippe Brucker <jean-philippe.bruc...@arm.com>; Joerg Roedel >> <j...@8byt

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On 2017/10/12 17:50, Liu, Yi L wrote: > > >> -Original Message----- >> From: Bob Liu [mailto:liub...@huawei.com] >> Sent: Thursday, October 12, 2017 5:39 PM >> To: Jean-Philippe Brucker ; Joerg Roedel >> ; Liu, Yi L >> Cc: Lan, Tianyu ; Liu,

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On 2017/10/11 20:48, Jean-Philippe Brucker wrote: > On 11/10/17 13:15, Joerg Roedel wrote: >> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: >>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea? >> >> It's short for IO Virtual Memory, basically a replacement term

Re: [PATCH v2 03/16] iommu: introduce iommu invalidate API function

On 2017/10/11 20:48, Jean-Philippe Brucker wrote: > On 11/10/17 13:15, Joerg Roedel wrote: >> On Wed, Oct 11, 2017 at 11:54:52AM +, Liu, Yi L wrote: >>> I didn't quite get 'iovm' mean. Can you explain a bit about the idea? >> >> It's short for IO Virtual Memory, basically a replacement term

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Sun, Oct 1, 2017 at 6:49 AM, Jerome Glisse <jgli...@redhat.com> wrote: > On Sat, Sep 30, 2017 at 10:57:38AM +0800, Bob Liu wrote: >> On 2017/9/27 0:16, Jerome Glisse wrote: >> > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote: >> >> On Tue, Sep 12,

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Sun, Oct 1, 2017 at 6:49 AM, Jerome Glisse wrote: > On Sat, Sep 30, 2017 at 10:57:38AM +0800, Bob Liu wrote: >> On 2017/9/27 0:16, Jerome Glisse wrote: >> > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote: >> >> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Gli

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/9/27 0:16, Jerome Glisse wrote: > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote: >> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse <jgli...@redhat.com> wrote: >>> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: >>>> On Wed, Sep 6,

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/9/27 0:16, Jerome Glisse wrote: > On Tue, Sep 26, 2017 at 05:56:26PM +0800, Bob Liu wrote: >> On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse wrote: >>> On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: >>>> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Gliss

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse <jgli...@redhat.com> wrote: > On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: >> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse <jgli...@redhat.com> wrote: >> > On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Willia

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Tue, Sep 12, 2017 at 7:36 AM, Jerome Glisse wrote: > On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: >> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse wrote: >> > On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: >> >> On Thu, Jul 20, 2017 at

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/6 17:57, Jean-Philippe Brucker wrote: > On 06/09/17 02:02, Bob Liu wrote: >> On 2017/9/5 20:56, Jean-Philippe Brucker wrote: >>> On 31/08/17 09:20, Yisheng Xie wrote: >>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM >>>

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/6 17:57, Jean-Philippe Brucker wrote: > On 06/09/17 02:02, Bob Liu wrote: >> On 2017/9/5 20:56, Jean-Philippe Brucker wrote: >>> On 31/08/17 09:20, Yisheng Xie wrote: >>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM >>>

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/9/12 7:36, Jerome Glisse wrote: > On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: >> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse <jgli...@redhat.com> wrote: >>> On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: >>>> On Thu, Ju

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/9/12 7:36, Jerome Glisse wrote: > On Sun, Sep 10, 2017 at 07:22:58AM +0800, Bob Liu wrote: >> On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse wrote: >>> On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: >>>> On Thu, Jul 20, 2017 at 6:41 PM, Jero

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse <jgli...@redhat.com> wrote: > On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: >> On Thu, Jul 20, 2017 at 6:41 PM, Jerome Glisse <jgli...@redhat.com> wrote: >> > On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Wed, Sep 6, 2017 at 3:36 AM, Jerome Glisse wrote: > On Thu, Jul 20, 2017 at 08:48:20PM -0700, Dan Williams wrote: >> On Thu, Jul 20, 2017 at 6:41 PM, Jerome Glisse wrote: >> > On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: >> >> On 2017/7

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/8 1:27, Jerome Glisse wrote: >> On 2017/9/6 10:12, Jerome Glisse wrote: >>> On Wed, Sep 06, 2017 at 09:25:36AM +0800, Bob Liu wrote: >>>> On 2017/9/6 2:54, Ross Zwisler wrote: >>>>> On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote:

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/8 1:27, Jerome Glisse wrote: >> On 2017/9/6 10:12, Jerome Glisse wrote: >>> On Wed, Sep 06, 2017 at 09:25:36AM +0800, Bob Liu wrote: >>>> On 2017/9/6 2:54, Ross Zwisler wrote: >>>>> On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote:

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/6 10:12, Jerome Glisse wrote: > On Wed, Sep 06, 2017 at 09:25:36AM +0800, Bob Liu wrote: >> On 2017/9/6 2:54, Ross Zwisler wrote: >>> On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote: >>>> On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/6 10:12, Jerome Glisse wrote: > On Wed, Sep 06, 2017 at 09:25:36AM +0800, Bob Liu wrote: >> On 2017/9/6 2:54, Ross Zwisler wrote: >>> On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote: >>>> On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/6 17:59, Jean-Philippe Brucker wrote: > On 06/09/17 02:16, Yisheng Xie wrote: >> Hi Jean-Philippe, >> >> On 2017/9/5 20:56, Jean-Philippe Brucker wrote: >>> On 31/08/17 09:20, Yisheng Xie wrote: Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/6 17:59, Jean-Philippe Brucker wrote: > On 06/09/17 02:16, Yisheng Xie wrote: >> Hi Jean-Philippe, >> >> On 2017/9/5 20:56, Jean-Philippe Brucker wrote: >>> On 31/08/17 09:20, Yisheng Xie wrote: Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3:

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/6 17:57, Jean-Philippe Brucker wrote: > On 06/09/17 02:02, Bob Liu wrote: >> On 2017/9/5 20:56, Jean-Philippe Brucker wrote: >>> On 31/08/17 09:20, Yisheng Xie wrote: >>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM >>>

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/6 17:57, Jean-Philippe Brucker wrote: > On 06/09/17 02:02, Bob Liu wrote: >> On 2017/9/5 20:56, Jean-Philippe Brucker wrote: >>> On 31/08/17 09:20, Yisheng Xie wrote: >>>> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM >>>

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/6 2:54, Ross Zwisler wrote: > On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote: >> On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote: >>> On 2017/9/4 23:51, Jerome Glisse wrote: >>>> On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/6 2:54, Ross Zwisler wrote: > On Mon, Sep 04, 2017 at 10:38:27PM -0400, Jerome Glisse wrote: >> On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote: >>> On 2017/9/4 23:51, Jerome Glisse wrote: >>>> On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/5 20:56, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: >> https://www.spinics.net/lists/arm-kernel/msg565155.html >> >> But for some platform devices(aka on-chip integrated devices),

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/9/5 20:56, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: >> https://www.spinics.net/lists/arm-kernel/msg565155.html >> >> But for some platform devices(aka on-chip integrated devices),

Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

On 2017/9/5 20:53, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> From: Jean-Philippe Brucker >> >> Platform device can realise SVM function by using the stall mode. That >> is to say, when device access a memory via iova which is not

Re: [RFC PATCH 4/6] iommu/arm-smmu-v3: Add SVM support for platform devices

On 2017/9/5 20:53, Jean-Philippe Brucker wrote: > On 31/08/17 09:20, Yisheng Xie wrote: >> From: Jean-Philippe Brucker >> >> Platform device can realise SVM function by using the stall mode. That >> is to say, when device access a memory via iova which is not populated, >> it will stalled and

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/5 10:38, Jerome Glisse wrote: > On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote: >> On 2017/9/4 23:51, Jerome Glisse wrote: >>> On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: >>>> On 2017/8/17 8:05, Jérôme Glisse wrote: >>>>>

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/5 10:38, Jerome Glisse wrote: > On Tue, Sep 05, 2017 at 09:13:24AM +0800, Bob Liu wrote: >> On 2017/9/4 23:51, Jerome Glisse wrote: >>> On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: >>>> On 2017/8/17 8:05, Jérôme Glisse wrote: >>>>>

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/4 23:51, Jerome Glisse wrote: > On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: >> On 2017/8/17 8:05, Jérôme Glisse wrote: >>> Unlike unaddressable memory, coherent device memory has a real >>> resource associated with it on the system (as CPU can

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

On 2017/9/4 23:51, Jerome Glisse wrote: > On Mon, Sep 04, 2017 at 11:09:14AM +0800, Bob Liu wrote: >> On 2017/8/17 8:05, Jérôme Glisse wrote: >>> Unlike unaddressable memory, coherent device memory has a real >>> resource associated with it on the system (as CPU can

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

evice( e.g CCIX) memory are likely reported to OS through ACPI and recognized as NUMA memory node. Then how can their memory be captured and managed by HMM framework? -- Regards, Bob Liu > Changed since v2: > - s/host/public > Changed since v1: > - s/public/host > > S

Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3

evice( e.g CCIX) memory are likely reported to OS through ACPI and recognized as NUMA memory node. Then how can their memory be captured and managed by HMM framework? -- Regards, Bob Liu > Changed since v2: > - s/host/public > Changed since v1: > - s/public/host > > Signed-

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Fri, Jul 21, 2017 at 10:10 AM, Bob Liu <liub...@huawei.com> wrote: > On 2017/7/21 9:41, Jerome Glisse wrote: >> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: >>> On 2017/7/20 23:03, Jerome Glisse wrote: >>>> On Wed, Jul 19, 2017 at 05:09:04PM +080

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On Fri, Jul 21, 2017 at 10:10 AM, Bob Liu wrote: > On 2017/7/21 9:41, Jerome Glisse wrote: >> On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: >>> On 2017/7/20 23:03, Jerome Glisse wrote: >>>> On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: >>&

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/21 9:41, Jerome Glisse wrote: > On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: >> On 2017/7/20 23:03, Jerome Glisse wrote: >>> On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: >>>> On 2017/7/19 10:25, Jerome Glisse wrote: >>>>

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/21 9:41, Jerome Glisse wrote: > On Fri, Jul 21, 2017 at 09:15:29AM +0800, Bob Liu wrote: >> On 2017/7/20 23:03, Jerome Glisse wrote: >>> On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: >>>> On 2017/7/19 10:25, Jerome Glisse wrote: >>>>

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/20 23:03, Jerome Glisse wrote: > On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: >> On 2017/7/19 10:25, Jerome Glisse wrote: >>> On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote: >>>> On 2017/7/18 23:38, Jerome Glisse wrote: >>>>

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/20 23:03, Jerome Glisse wrote: > On Wed, Jul 19, 2017 at 05:09:04PM +0800, Bob Liu wrote: >> On 2017/7/19 10:25, Jerome Glisse wrote: >>> On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote: >>>> On 2017/7/18 23:38, Jerome Glisse wrote: >>>>

Re: [RFC v2 0/5] surface heterogeneous memory performance information

ry allocations that meet a given set of > performance characteristics. > > Option 2: Provide the user with HMAT performance data directly in sysfs, > allowing applications to directly access it without the need for the > library and daemon. > Is it possible to do the memory allocatio

Re: [RFC v2 0/5] surface heterogeneous memory performance information

ry allocations that meet a given set of > performance characteristics. > > Option 2: Provide the user with HMAT performance data directly in sysfs, > allowing applications to directly access it without the need for the > library and daemon. > Is it possible to do the memory allocatio

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/19 10:25, Jerome Glisse wrote: > On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote: >> On 2017/7/18 23:38, Jerome Glisse wrote: >>> On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote: >>>> On 2017/7/14 5:15, Jérôme Glisse wrote: >>>&g

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/19 10:25, Jerome Glisse wrote: > On Wed, Jul 19, 2017 at 09:46:10AM +0800, Bob Liu wrote: >> On 2017/7/18 23:38, Jerome Glisse wrote: >>> On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote: >>>> On 2017/7/14 5:15, Jérôme Glisse wrote: >>>&g

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/18 23:38, Jerome Glisse wrote: > On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote: >> On 2017/7/14 5:15, Jérôme Glisse wrote: >>> Sorry i made horrible mistake on names in v4, i completly miss- >>> understood the suggestion. So here

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

On 2017/7/18 23:38, Jerome Glisse wrote: > On Tue, Jul 18, 2017 at 11:26:51AM +0800, Bob Liu wrote: >> On 2017/7/14 5:15, Jérôme Glisse wrote: >>> Sorry i made horrible mistake on names in v4, i completly miss- >>> understood the suggestion. So here

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

distance for "Cache Coherent Device Memory" may be a easier way to address these concerns. -- Regards, Bob Liu > This patchset add a new type of ZONE_DEVICE memory (DEVICE_HOST) > that is use to represent CDM memory. This patchset build on top of > the HMM patchset that already i

Re: [PATCH 0/6] Cache coherent device memory (CDM) with HMM v5

distance for "Cache Coherent Device Memory" may be a easier way to address these concerns. -- Regards, Bob Liu > This patchset add a new type of ZONE_DEVICE memory (DEVICE_HOST) > that is use to represent CDM memory. This patchset build on top of > the HMM patchset that already i

Re: [HMM 00/15] HMM (Heterogeneous Memory Management) v23

ate these two things into two patchsets? Which will make it's more easy to review and also follow the "Do one thing, and do it well" philosophy. Thanks, Bob Liu

Re: [HMM 00/15] HMM (Heterogeneous Memory Management) v23

two patchsets? Which will make it's more easy to review and also follow the "Do one thing, and do it well" philosophy. Thanks, Bob Liu

Re: [PATCH v7 0/7] Introduce ZONE_CMA

> earlier, MM subsystem already have many infrastructures to deal with > zone's H/W addressing limitation. Adding S/W limitation on zone concept > and adding a new zone doesn't change anything. It will work by itself. > My patchset can remove many hooks related to CMA area management in MM > while solving the problems. More hooks are required to solve the problems > if we choose MIGRATETYPE approach. > Agree, there are already too many hooks and pain to maintain/bugfix. It looks better if choose this ZONE_CMA approach. -- Regards, Bob Liu

Re: [PATCH v7 0/7] Introduce ZONE_CMA

ready have many infrastructures to deal with > zone's H/W addressing limitation. Adding S/W limitation on zone concept > and adding a new zone doesn't change anything. It will work by itself. > My patchset can remove many hooks related to CMA area management in MM > while solving the problems. More hooks are required to solve the problems > if we choose MIGRATETYPE approach. > Agree, there are already too many hooks and pain to maintain/bugfix. It looks better if choose this ZONE_CMA approach. -- Regards, Bob Liu

Re: [HMM 00/16] HMM (Heterogeneous Memory Management) v18

On 2017/3/17 7:49, Jerome Glisse wrote: > On Thu, Mar 16, 2017 at 01:43:21PM -0700, Andrew Morton wrote: >> On Thu, 16 Mar 2017 12:05:19 -0400 J__r__me Glisse >> wrote: >> >>> Cliff note: >> >> "Cliff's notes" isn't appropriate for a large feature such as this. >> Where's

Re: [HMM 00/16] HMM (Heterogeneous Memory Management) v18

On 2017/3/17 7:49, Jerome Glisse wrote: > On Thu, Mar 16, 2017 at 01:43:21PM -0700, Andrew Morton wrote: >> On Thu, 16 Mar 2017 12:05:19 -0400 J__r__me Glisse >> wrote: >> >>> Cliff note: >> >> "Cliff's notes" isn't appropriate for a large feature such as this. >> Where's the long-form

Re: [HMM 00/16] HMM (Heterogeneous Memory Management) v18

On 2017/3/17 7:49, Jerome Glisse wrote: > On Thu, Mar 16, 2017 at 01:43:21PM -0700, Andrew Morton wrote: >> On Thu, 16 Mar 2017 12:05:19 -0400 J__r__me Glisse >> wrote: >> >>> Cliff note: >> >> "Cliff's notes" isn't appropriate for a large feature such as this. >> Where's

Re: [HMM 00/16] HMM (Heterogeneous Memory Management) v18

On 2017/3/17 7:49, Jerome Glisse wrote: > On Thu, Mar 16, 2017 at 01:43:21PM -0700, Andrew Morton wrote: >> On Thu, 16 Mar 2017 12:05:19 -0400 J__r__me Glisse >> wrote: >> >>> Cliff note: >> >> "Cliff's notes" isn't appropriate for a large feature such as this. >> Where's the long-form

Re: [HMM 16/16] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v2

Hi Jérôme, On 2017/3/17 0:05, Jérôme Glisse wrote: > This introduce a dummy HMM device class so device driver can use it to > create hmm_device for the sole purpose of registering device memory. May I ask where is the latest dummy HMM device driver? I can only get this one:

Re: [HMM 16/16] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v2

Hi Jérôme, On 2017/3/17 0:05, Jérôme Glisse wrote: > This introduce a dummy HMM device class so device driver can use it to > create hmm_device for the sole purpose of registering device memory. May I ask where is the latest dummy HMM device driver? I can only get this one:

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On 2017/3/2 13:19, Xiong Zhou wrote: > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote: >>> Hi, >>> >>> It's reproduciable, not everytime though. Ext4 works fine. >> >> On ext4 fsstress won't run bulkstat because it

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On 2017/3/2 13:19, Xiong Zhou wrote: > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: >> On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote: >>> Hi, >>> >>> It's reproduciable, not everytime though. Ext4 works fine. >> >> On ext4 fsstress won't run bulkstat because it

Re: [PATCH V3 0/4] Define coherent device memory node

On 2017/2/24 12:53, Jerome Glisse wrote: > On Fri, Feb 24, 2017 at 09:06:19AM +0800, Bob Liu wrote: >> On 2017/2/21 21:39, Anshuman Khandual wrote: >>> On 02/21/2017 04:41 PM, Michal Hocko wrote: >>>> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote: >>>

Re: [PATCH V3 0/4] Define coherent device memory node

On 2017/2/24 12:53, Jerome Glisse wrote: > On Fri, Feb 24, 2017 at 09:06:19AM +0800, Bob Liu wrote: >> On 2017/2/21 21:39, Anshuman Khandual wrote: >>> On 02/21/2017 04:41 PM, Michal Hocko wrote: >>>> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote: >>>

Re: [PATCH V3 0/4] Define coherent device memory node

On 2017/2/21 21:39, Anshuman Khandual wrote: > On 02/21/2017 04:41 PM, Michal Hocko wrote: >> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote: >> [...] >>> * User space using mbind() to get CDM memory is an additional benefit >>> we get by making the CDM plug in as a node and be part of the

Re: [PATCH V3 0/4] Define coherent device memory node

On 2017/2/21 21:39, Anshuman Khandual wrote: > On 02/21/2017 04:41 PM, Michal Hocko wrote: >> On Fri 17-02-17 17:11:57, Anshuman Khandual wrote: >> [...] >>> * User space using mbind() to get CDM memory is an additional benefit >>> we get by making the CDM plug in as a node and be part of the

Re: [PATCH V3 1/4] mm: Define coherent device memory (CDM) node

Hi Anshuman, I have a few questions about coherent device memory. On Wed, Feb 15, 2017 at 8:07 PM, Anshuman Khandual wrote: > There are certain devices like specialized accelerator, GPU cards, network > cards, FPGA cards etc which might contain onboard memory which

Re: [PATCH V3 1/4] mm: Define coherent device memory (CDM) node

Hi Anshuman, I have a few questions about coherent device memory. On Wed, Feb 15, 2017 at 8:07 PM, Anshuman Khandual wrote: > There are certain devices like specialized accelerator, GPU cards, network > cards, FPGA cards etc which might contain onboard memory which is coherent > along with the

[PATCH] block: xen-blkback: don't get/put blkif ref for each queue

xen_blkif_deferred_free() to free resources anymore. Signed-off-by: Bob Liu <bob@oracle.com> --- drivers/block/xen-blkback/xenbus.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 3cc6d1d..2e1bb6d

[PATCH] block: xen-blkback: don't get/put blkif ref for each queue

xen_blkif_deferred_free() to free resources anymore. Signed-off-by: Bob Liu --- drivers/block/xen-blkback/xenbus.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-blkback/xenbus.c index 3cc6d1d..2e1bb6d 100644 --- a/drivers/block/xen

Re: [PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

On 07/28/2016 09:19 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Jul 26, 2016 at 01:19:35PM +0800, Bob Liu wrote: >> Two places didn't get updated when 64KB page granularity was introduced, this >> patch fix them. >> >> Signed-off-by: Bob Liu <bob@oracle.com> &g

Re: [PATCH 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

On 07/28/2016 09:19 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Jul 26, 2016 at 01:19:35PM +0800, Bob Liu wrote: >> Two places didn't get updated when 64KB page granularity was introduced, this >> patch fix them. >> >> Signed-off-by: Bob Liu >> Acked-by: Roger

[PATCH v2 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

Two places didn't get updated when 64KB page granularity was introduced, this patch fix them. Signed-off-by: Bob Liu <bob@oracle.com> Acked-by: Roger Pau Monné <roger@citrix.com> --- drivers/block/xen-blkfront.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH v2 1/3] xen-blkfront: fix places not updated after introducing 64KB page granularity

Two places didn't get updated when 64KB page granularity was introduced, this patch fix them. Signed-off-by: Bob Liu Acked-by: Roger Pau Monné --- drivers/block/xen-blkfront.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers

[PATCH 3/3] xen-blkfront: free resources if xlvbd_alloc_gendisk fails

Current code forgets to free resources in the failure path of xlvbd_alloc_gendisk(), this patch fix it. Signed-off-by: Bob Liu <bob@oracle.com> --- drivers/block/xen-blkfront.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/block/xen-blkfront.c b/d

[PATCH 3/3] xen-blkfront: free resources if xlvbd_alloc_gendisk fails

Current code forgets to free resources in the failure path of xlvbd_alloc_gendisk(), this patch fix it. Signed-off-by: Bob Liu --- drivers/block/xen-blkfront.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen

[PATCH v2 2/3] xen-blkfront: introduce blkif_set_queue_limits()

blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits with initial correct values. Signed-off-by: Bob Liu <bob@oracle.com> Acked-by: Roger Pau Monné <roger@citrix.com> --- d

[PATCH v2 2/3] xen-blkfront: introduce blkif_set_queue_limits()

blk_mq_update_nr_hw_queues() reset all queue limits to default which it's not as xen-blkfront expected, introducing blkif_set_queue_limits() to reset limits with initial correct values. Signed-off-by: Bob Liu Acked-by: Roger Pau Monné --- drivers/block/xen-blkfront.c | 87

Re: [PATCH] drivers: virtio_blk: notify blk-core when hw-queue number changes

On 06/19/2016 06:10 AM, Paolo Bonzini wrote: > > > On 13/06/2016 11:58, Bob Liu wrote: >> A guest might be migrated to other hosts with different num_queues, the >> blk-core should aware of that else the reference of >vqs[qid] may be >> wrong. >> >>

Re: [PATCH] drivers: virtio_blk: notify blk-core when hw-queue number changes

On 06/19/2016 06:10 AM, Paolo Bonzini wrote: > > > On 13/06/2016 11:58, Bob Liu wrote: >> A guest might be migrated to other hosts with different num_queues, the >> blk-core should aware of that else the reference of >vqs[qid] may be >> wrong. >> >>

Re: [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/27/2016 10:24 PM, Roger Pau Monné wrote: > On Wed, Jul 27, 2016 at 07:21:05PM +0800, Bob Liu wrote: >> >> On 07/27/2016 06:59 PM, Roger Pau Monné wrote: >>> On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote: >>> [...] >>>> +static ssize_t

Re: [PATCH v3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/27/2016 10:24 PM, Roger Pau Monné wrote: > On Wed, Jul 27, 2016 at 07:21:05PM +0800, Bob Liu wrote: >> >> On 07/27/2016 06:59 PM, Roger Pau Monné wrote: >>> On Wed, Jul 27, 2016 at 11:21:25AM +0800, Bob Liu wrote: >>> [...] >>>> +static ssize_t

  1   2   3   4   5   6   7   8   9   >