Hi,
Please consider pulling the following changes for the GFS2 file system.
I apologize for the late request, but as I explained in my previous email,
I wanted to make sure everything was done "the right way."
Bo
Hi,
Please consider pulling the following changes for the GFS2 file system.
I apologize for the late request, but as I explained in my previous email,
I wanted to make sure everything was done "the right way."
Bo
l of them are pretty much
confined to GFS2 (except for new calls to rhashtable functions) so
hopefully this is just a formality. Sorry for the delay.
Regards,
Bob Peterson
GFS2 Maintainer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
l of them are pretty much
confined to GFS2 (except for new calls to rhashtable functions) so
hopefully this is just a formality. Sorry for the delay.
Regards,
Bob Peterson
GFS2 Maintainer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On 09/07/2015 07:10 PM, Julien Grall wrote:
> On 07/09/15 07:07, Bob Liu wrote:
>> Hi Julien,
>
> Hi Bob,
>
>> On 09/04/2015 09:51 PM, Julien Grall wrote:
>>> Hi Roger,
>>>
>>> On 04/09/15 11:08, Roger Pau Monne wrote:
>>>> Req
oris Ostrovsky
>> Cc: David Vrabel
>> Cc: xen-de...@lists.xenproject.org
>
> The patch is fixing my problem when using UEFI in the guest. Thank you!
>
Could you please explain the problem you met a bit more?
So that I can know back port this patch if met similar issue.
Th
my problem when using UEFI in the guest. Thank you!
>
Could you please explain the problem you met a bit more?
So that I can know back port this patch if met similar issue.
Thanks,
-Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 09/07/2015 07:10 PM, Julien Grall wrote:
> On 07/09/15 07:07, Bob Liu wrote:
>> Hi Julien,
>
> Hi Bob,
>
>> On 09/04/2015 09:51 PM, Julien Grall wrote:
>>> Hi Roger,
>>>
>>> On 04/09/15 11:08, Roger Pau Monne wrote:
>>>> Req
Prepare patch for multi hardware queues/rings, the ring number was set to 1 by
force.
Signed-off-by: Arianna Avanzini
Signed-off-by: Bob Liu
---
drivers/block/xen-blkback/common.h |3 +-
drivers/block/xen-blkback/xenbus.c | 328 +++-
2 files changed, 209
Split per ring information to an new structure:xen_blkif_ring, so that one vbd
device can associate with one or more rings/hardware queues.
This patch is a preparation for supporting multi hardware queues/rings.
Signed-off-by: Arianna Avanzini
Signed-off-by: Bob Liu
---
drivers/block/xen
ueues".
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c | 142 --
1 file changed, 108 insertions(+), 34 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 1cae76b..1aa66c9 100644
--- a/drivers/block/
Backend advertises "multi-queue-max-queues" to front, and then read back the
final negotiated queues/rings from "multi-queue-num-queues" which is wrote by
blkfront.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkback/blkback.c |8
drivers/block/xen-blkb
The per device io_lock became a coarser grained lock after multi-queues/rings
was introduced, this patch converts it to a fine-grained per ring lock.
NOTE: The per dev_info structure was no more protected by any lock.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c | 44
ter.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c | 513 +-
1 file changed, 308 insertions(+), 205 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index bf416d5..bf45c99 100644
--- a/drivers/block/
.
This patch is a preparation for supporting real multi hardware queues/rings.
Signed-off-by: Arianna Avanzini
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c | 854 ++
1 file changed, 445 insertions(+), 409 deletions(-)
diff --git a/drivers/block/xen
, and nvme.
Also dropped one unnecessary holding of info->io_lock when calling
blk_mq_stop_hw_queues().
Signed-off-by: Arianna Avanzini
Signed-off-by: Bob Liu
Reviewed-by: Christoph Hellwig
Acked-by: Jens Axboe
Signed-off-by: David Vrabel
---
drivers/block/xen-blkfront.c |
Document multi queues/rings of xen-block.
Signed-off-by: Bob Liu
---
include/xen/interface/io/blkif.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index c33e1c4..b453b70 100644
ps: 1310k279k810k(+200%) 871k 1000k
Only with 4queues, iops for domU get improved a lot and nearly catch up with
dom0. There were also similar huge improvement for write and real SSD storage.
---
v3: Rebased to v4.2-rc8
Bob Liu (9):
xen-blkfront: convert to blk-mq
ueues".
Signed-off-by: Bob Liu <bob@oracle.com>
---
drivers/block/xen-blkfront.c | 142 --
1 file changed, 108 insertions(+), 34 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 1cae76b..1aa66c9 1006
Backend advertises "multi-queue-max-queues" to front, and then read back the
final negotiated queues/rings from "multi-queue-num-queues" which is wrote by
blkfront.
Signed-off-by: Bob Liu <bob@oracle.com>
---
drivers/block/xen-blkback/blkback.c |8
The per device io_lock became a coarser grained lock after multi-queues/rings
was introduced, this patch converts it to a fine-grained per ring lock.
NOTE: The per dev_info structure was no more protected by any lock.
Signed-off-by: Bob Liu <bob@oracle.com>
---
drivers/block/xen-blkf
ter.
Signed-off-by: Bob Liu <bob@oracle.com>
---
drivers/block/xen-blkfront.c | 513 +-
1 file changed, 308 insertions(+), 205 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index bf416d5..bf45c
.
This patch is a preparation for supporting real multi hardware queues/rings.
Signed-off-by: Arianna Avanzini <avanzini.aria...@gmail.com>
Signed-off-by: Bob Liu <bob@oracle.com>
---
drivers/block/xen-blkfront.c | 854 ++
1 file changed, 44
Split per ring information to an new structure:xen_blkif_ring, so that one vbd
device can associate with one or more rings/hardware queues.
This patch is a preparation for supporting multi hardware queues/rings.
Signed-off-by: Arianna Avanzini <avanzini.aria...@gmail.com>
Signed-off-by: B
Prepare patch for multi hardware queues/rings, the ring number was set to 1 by
force.
Signed-off-by: Arianna Avanzini <avanzini.aria...@gmail.com>
Signed-off-by: Bob Liu <bob@oracle.com>
---
drivers/block/xen-blkback/common.h |3 +-
drivers/block/xen-blkback/xen
, and nvme.
Also dropped one unnecessary holding of info->io_lock when calling
blk_mq_stop_hw_queues().
Signed-off-by: Arianna Avanzini <avanzini.aria...@gmail.com>
Signed-off-by: Bob Liu <bob@oracle.com>
Reviewed-by: Christoph Hellwig <h...@lst.de>
Acked-by: Jens Axboe <
Document multi queues/rings of xen-block.
Signed-off-by: Bob Liu <bob@oracle.com>
---
include/xen/interface/io/blkif.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/xen/interface/io/blkif.h b/include/xen/interface/io/blkif.h
index c
ps: 1310k279k810k(+200%) 871k 1000k
Only with 4queues, iops for domU get improved a lot and nearly catch up with
dom0. There were also similar huge improvement for write and real SSD storage.
---
v3: Rebased to v4.2-rc8
Bob Liu (9):
xen-blkfront: convert to blk-mq
Hi Rafal,
Please have a try adding "--iodepth_batch=32 --iodepth_batch_complete=32" to
the fio command line.
I didn't see this issue any more, neither for domU.
Thanks,
-Bob
On 08/21/2015 04:46 PM, Rafal Mielniczuk wrote:
> On 19/08/15 12:12, Bob Liu wrote:
>> Hi Jens &
Hi Rafal,
Please have a try adding --iodepth_batch=32 --iodepth_batch_complete=32 to
the fio command line.
I didn't see this issue any more, neither for domU.
Thanks,
-Bob
On 08/21/2015 04:46 PM, Rafal Mielniczuk wrote:
On 19/08/15 12:12, Bob Liu wrote:
Hi Jens Christoph,
Rafal reported
s,
mint=30002msec, maxt=30002msec
Disk stats (read/write):
xvdb: ios=734048/0, merge=0/0, ticks=843584/0, in_queue=843080, util=99.72%
Regards,
-Bob
On 07/13/2015 05:55 PM, Bob Liu wrote:
> Note: This patch is based on original work of Arianna's internship for
> GNOME's Outreach Program for
=30002msec
Disk stats (read/write):
xvdb: ios=734048/0, merge=0/0, ticks=843584/0, in_queue=843080, util=99.72%
Regards,
-Bob
On 07/13/2015 05:55 PM, Bob Liu wrote:
Note: This patch is based on original work of Arianna's internship for
GNOME's Outreach Program for Women.
Only one hardware queue
On 08/13/2015 12:46 AM, Rafal Mielniczuk wrote:
> On 12/08/15 11:17, Bob Liu wrote:
>> On 08/12/2015 01:32 AM, Jens Axboe wrote:
>>> On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote:
>>>> On 11/08/15 07:08, Bob Liu wrote:
>>>>> On 08/10/2015 11:52 PM, Je
On 08/13/2015 12:46 AM, Rafal Mielniczuk wrote:
On 12/08/15 11:17, Bob Liu wrote:
On 08/12/2015 01:32 AM, Jens Axboe wrote:
On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote:
On 11/08/15 07:08, Bob Liu wrote:
On 08/10/2015 11:52 PM, Jens Axboe wrote:
On 08/10/2015 05:03 AM, Rafal Mielniczuk
On 08/12/2015 01:32 AM, Jens Axboe wrote:
> On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote:
>> On 11/08/15 07:08, Bob Liu wrote:
>>> On 08/10/2015 11:52 PM, Jens Axboe wrote:
>>>> On 08/10/2015 05:03 AM, Rafal Mielniczuk wrote:
...
>>>>> Hello,
>&g
On 08/12/2015 01:32 AM, Jens Axboe wrote:
On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote:
On 11/08/15 07:08, Bob Liu wrote:
On 08/10/2015 11:52 PM, Jens Axboe wrote:
On 08/10/2015 05:03 AM, Rafal Mielniczuk wrote:
...
Hello,
We rerun the tests for sequential reads with the identical
ops was better than single queue iops for all the block sizes.
>>>> There were very good improvements as well for sequential writes with
>>>> block size 4K (from 80K iops with single queue to 230K iops with 8
>>>> queues), and no regressions were visible in any measu
to this again.
Personally I'd be really interested in the results for the same set of
tests, but without the blk-mq patches. Do you have them, or could you
potentially run them?
Hello,
We rerun the tests for sequential reads with the identical settings but with
Bob Liu's multiqueue patches reverted
;> queues), and no regressions were visible in any measurement performed.
>> Great results! And I don't know why this code has lingered for so long,
>> so thanks for helping get some attention to this again.
>>
>> Personally I'd be really interested in the results fo
in the results for the same set of
tests, but without the blk-mq patches. Do you have them, or could you
potentially run them?
Hello,
We rerun the tests for sequential reads with the identical settings but with
Bob Liu's multiqueue patches reverted from dom0 and guest kernels.
The results we
On Fri, Aug 07, 2015 at 09:59:30AM +0200, Andrzej Hajda wrote:
> The patch was generated using fixed coccinelle semantic patch
> scripts/coccinelle/api/memdup.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2014320
>
> Signed-off-by: Andrzej Hajda
Thank
-by: Bob Copeland m...@bobcopeland.com
--
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
descriptors and
flush/barrier features to a separate function and call it from both
blkfront_connect and blkif_recover
Signed-off-by: Bob Liu
---
Changes in v2:
* Also put blkfront_setup_indirect() inside
---
drivers/block/xen-blkfront.c | 122 +++---
1 file
The BUG_ON() in purge_persistent_gnt() will be triggered when previous purge
work haven't finished.
There is a work_pending() before this BUG_ON, but it doesn't account if the work
is still currently running.
Signed-off-by: Bob Liu
---
Change in v2:
* Replace with work_busy()
---
drivers/block
We should consider info->feature_persistent when adding indriect page to list
info->indirect_pages, else the BUG_ON() in blkif_free() would be triggered.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/d
descriptors and
flush/barrier features to a separate function and call it from both
blkfront_connect and blkif_recover
Signed-off-by: Bob Liu bob@oracle.com
---
Changes in v2:
* Also put blkfront_setup_indirect() inside
---
drivers/block/xen-blkfront.c | 122
We should consider info-feature_persistent when adding indriect page to list
info-indirect_pages, else the BUG_ON() in blkif_free() would be triggered.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
The BUG_ON() in purge_persistent_gnt() will be triggered when previous purge
work haven't finished.
There is a work_pending() before this BUG_ON, but it doesn't account if the work
is still currently running.
Signed-off-by: Bob Liu bob@oracle.com
---
Change in v2:
* Replace with work_busy
On 07/22/2015 12:43 PM, Bob Liu wrote:
>
> On 07/21/2015 05:25 PM, Roger Pau Monné wrote:
>> El 21/07/15 a les 5.30, Bob Liu ha escrit:
>>> This BUG_ON() in blkif_free() is incorrect, because indirect page can be
>>> added
>>> to list info->indi
On 07/21/2015 05:25 PM, Roger Pau Monné wrote:
> El 21/07/15 a les 5.30, Bob Liu ha escrit:
>> This BUG_ON() in blkif_free() is incorrect, because indirect page can be
>> added
>> to list info->indirect_pages in blkif_completion() no matter
>> feature_
On 07/21/2015 05:13 PM, Roger Pau Monné wrote:
> El 21/07/15 a les 5.30, Bob Liu ha escrit:
>> This BUG_ON() will be triggered when previous purge work haven't finished.
>> It's reasonable under pretty extreme load and should not panic the system.
>>
>> Signed-off-by:
On 07/22/2015 12:43 PM, Bob Liu wrote:
On 07/21/2015 05:25 PM, Roger Pau Monné wrote:
El 21/07/15 a les 5.30, Bob Liu ha escrit:
This BUG_ON() in blkif_free() is incorrect, because indirect page can be
added
to list info-indirect_pages in blkif_completion() no matter
feature_persistent
On 07/21/2015 05:25 PM, Roger Pau Monné wrote:
El 21/07/15 a les 5.30, Bob Liu ha escrit:
This BUG_ON() in blkif_free() is incorrect, because indirect page can be
added
to list info-indirect_pages in blkif_completion() no matter
feature_persistent
is true or false.
Signed-off-by: Bob
On 07/21/2015 05:13 PM, Roger Pau Monné wrote:
El 21/07/15 a les 5.30, Bob Liu ha escrit:
This BUG_ON() will be triggered when previous purge work haven't finished.
It's reasonable under pretty extreme load and should not panic the system.
Signed-off-by: Bob Liu bob@oracle.com
descriptors and
flush/barrier features to a separate function and call it from both
blkfront_connect and blkif_recover
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c | 118 +++---
1 file changed, 66 insertions(+), 52 deletions(-)
diff --git a/drivers/block
This BUG_ON() will be triggered when previous purge work haven't finished.
It's reasonable under pretty extreme load and should not panic the system.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkback/blkback.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers
This BUG_ON() in blkif_free() is incorrect, because indirect page can be added
to list info->indirect_pages in blkif_completion() no matter feature_persistent
is true or false.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c |1 -
1 file changed, 1 deletion(-)
diff --git a/driv
This BUG_ON() will be triggered when previous purge work haven't finished.
It's reasonable under pretty extreme load and should not panic the system.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/blkback.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion
This BUG_ON() in blkif_free() is incorrect, because indirect page can be added
to list info-indirect_pages in blkif_completion() no matter feature_persistent
is true or false.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c |1 -
1 file changed, 1 deletion(-)
diff
descriptors and
flush/barrier features to a separate function and call it from both
blkfront_connect and blkif_recover
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c | 118 +++---
1 file changed, 66 insertions(+), 52 deletions(-)
diff --git
S2_GL_HASH_SIZE * 3 / 4,
> .key_len = sizeof(struct lm_lockname),
> .key_offset = offsetof(struct gfs2_glock, gl_name),
>
Hi,
Thanks. Now pushed to the for-next branch of the linux-gfs2 tree.
Regards,
Bob Peterson
Red Hat File Systems
--
To unsubscribe from this list:
(struct lm_lockname),
.key_offset = offsetof(struct gfs2_glock, gl_name),
Hi,
Thanks. Now pushed to the for-next branch of the linux-gfs2 tree.
Regards,
Bob Peterson
Red Hat File Systems
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
dropped one unnecessary holding of info->io_lock when calling
blk_mq_stop_hw_queues().
Changes in v2:
- Reorganized blk_mq_queue_rq()
- Restored most io_locks in place
Change in v3:
- Rename blk_mq_queue_rq to blkif_queue_rq
Signed-off-by: Arianna Avanzini
Signed-off-by: Bob Liu
Revie
-by: Bob Liu bob@oracle.com
Reviewed-by: Christoph Hellwig h...@lst.de
Acked-by: Jens Axboe ax...@fb.com
---
drivers/block/xen-blkfront.c | 146 +-
1 file changed, 60 insertions(+), 86 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block
On 07/12/2015 02:14 AM, Jens Axboe wrote:
> On 07/11/2015 07:30 AM, Bob Liu wrote:
>> Note: This patch is based on original work of Arianna's internship for
>> GNOME's Outreach Program for Women.
>
> Great to see this finally get prepped to go in!
>
>> Only one
dropped one unnecessary holding of info->io_lock when calling
blk_mq_stop_hw_queues().
Changes in v2:
- Reorganized blk_mq_queue_rq()
- Restored most io_locks in place
Signed-off-by: Arianna Avanzini
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c |
On 07/11/2015 03:57 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 06, 2015 at 05:56:48PM +0800, Bob Liu wrote:
>> From: Arianna Avanzini
>>
>> This patch converts xen-blkfront driver to use the block multiqueue APIs.
>> Only one hardware queue is used now, so the
On 07/11/2015 03:57 AM, Konrad Rzeszutek Wilk wrote:
On Mon, Jul 06, 2015 at 05:56:48PM +0800, Bob Liu wrote:
From: Arianna Avanzini avanzini.aria...@gmail.com
This patch converts xen-blkfront driver to use the block multiqueue APIs.
Only one hardware queue is used now, so
dropped one unnecessary holding of info-io_lock when calling
blk_mq_stop_hw_queues().
Changes in v2:
- Reorganized blk_mq_queue_rq()
- Restored most io_locks in place
Signed-off-by: Arianna Avanzini avanzini.aria...@gmail.com
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen
On 07/12/2015 02:14 AM, Jens Axboe wrote:
On 07/11/2015 07:30 AM, Bob Liu wrote:
Note: This patch is based on original work of Arianna's internship for
GNOME's Outreach Program for Women.
Great to see this finally get prepped to go in!
Only one hardware queue is used now, so
t; Signed-off-by: Julien Grall
Also hit the same issue, thank you for the fix.
Tested-by: Bob Liu
> Cc: Bernhard Thaler
> Cc: Pablo Neira Ayuso
> Cc: f...@strlen.de
> Cc: ian.campb...@citrix.com
> Cc: wei.l...@citrix.com
>
> ---
> Note that it's impossible to crea
unnecessary holding of info->io_lock when calling into blk-mq APIs.
Signed-off-by: Arianna Avanzini
Signed-off-by: Bob Liu
---
drivers/block/xen-blkfront.c | 173 ++
1 file changed, 73 insertions(+), 100 deletions(-)
diff --git a/drivers/block/
, and nvme.
Also dropped unnecessary holding of info-io_lock when calling into blk-mq APIs.
Signed-off-by: Arianna Avanzini avanzini.aria...@gmail.com
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkfront.c | 173 ++
1 file changed, 73
issue, thank you for the fix.
Tested-by: Bob Liu bob@oracle.com
Cc: Bernhard Thaler bernhard.tha...@wvnet.at
Cc: Pablo Neira Ayuso pa...@netfilter.org
Cc: f...@strlen.de
Cc: ian.campb...@citrix.com
Cc: wei.l...@citrix.com
---
Note that it's impossible to create new guest after
On 06/30/2015 10:21 PM, Marcus Granado wrote:
> On 13/05/15 11:29, Bob Liu wrote:
>>
>> On 04/28/2015 03:46 PM, Arianna Avanzini wrote:
>>> Hello Christoph,
>>>
>>> Il 28/04/2015 09:36, Christoph Hellwig ha scritto:
>>>> What happened to t
On 06/30/2015 10:21 PM, Marcus Granado wrote:
On 13/05/15 11:29, Bob Liu wrote:
On 04/28/2015 03:46 PM, Arianna Avanzini wrote:
Hello Christoph,
Il 28/04/2015 09:36, Christoph Hellwig ha scritto:
What happened to this patchset?
It was passed on to Bob Liu, who published a follow-up
Hi,
Please consider pulling the following changes for the GFS2 file system.
Regards,
Bob Peterson
The following changes since commit f4a3ae9308e34bcd704325a08879b2c1cfb74686:
GFS2: Use average srttb value in congestion
Hi,
Please consider pulling the following changes for the GFS2 file system.
Regards,
Bob Peterson
The following changes since commit f4a3ae9308e34bcd704325a08879b2c1cfb74686:
GFS2: Use average srttb value in congestion
ches or not.
>
Hey,
Are there any updates? What's the performance regression problem?
Thanks,
-Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at http://www.tux.org/lkml/
regression on
some of their tests. I'm adding them to the conversation so they can
provide more details about the issues they found, and whether we should
hold pushing this patches or not.
Hey,
Are there any updates? What's the performance regression problem?
Thanks,
-Bob
--
To unsubscribe
- Original Message -
> Bob Peterson wrote:
> > - Original Message -
> >
> >> Hi Bob,
> >>
> >> Bob Peterson wrote:
> >>
> >>> - Original Message -
> >>>
> >>&
- Original Message -
Bob Peterson wrote:
- Original Message -
Hi Bob,
Bob Peterson wrote:
- Original Message -
We don't need the redundant logic since send_message always returns 0.
Signed-off-by: Guoqing Jiang gqji...@suse.com
- Original Message -
> Hi Bob,
>
> Bob Peterson wrote:
> > - Original Message -
> >
> >> We don't need the redundant logic since send_message always returns 0.
> >>
> >> Signed-off-by: Guoqing Jiang
> >> ---
&g
On 06/09/2015 09:39 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 09, 2015 at 08:52:53AM +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Bob Liu [mailto:bob@oracle.com]
>>> Sent: 09 June 2015 09:50
>>> To: Bob Liu
>>>
ks okay, but if remove_from_waiters() always returns 0,
wouldn't it be better to change the function from int to void and
return 0 here? The advantage is that code spelunkers wouldn't need
to back-track one more level (not to mention the instruction or two
it might save).
Regards,
Bob Peterson
Red
On 06/03/2015 01:40 PM, Bob Liu wrote:
> Extend xen/block to support multi-page ring, so that more requests can be
> issued by using more than one pages as the request ring between blkfront
> and backend.
> As a result, the performance can get improved significantly.
>
> We g
On 06/03/2015 01:40 PM, Bob Liu wrote:
Extend xen/block to support multi-page ring, so that more requests can be
issued by using more than one pages as the request ring between blkfront
and backend.
As a result, the performance can get improved significantly.
We got some impressive
? The advantage is that code spelunkers wouldn't need
to back-track one more level (not to mention the instruction or two
it might save).
Regards,
Bob Peterson
Red Hat File Systems
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
- Original Message -
Hi Bob,
Bob Peterson wrote:
- Original Message -
We don't need the redundant logic since send_message always returns 0.
Signed-off-by: Guoqing Jiang gqji...@suse.com
---
fs/dlm/lock.c | 10 ++
1 file changed, 2 insertions(+), 8
On 06/09/2015 09:39 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Jun 09, 2015 at 08:52:53AM +, Paul Durrant wrote:
-Original Message-
From: Bob Liu [mailto:bob@oracle.com]
Sent: 09 June 2015 09:50
To: Bob Liu
Cc: xen-de...@lists.xen.org; David Vrabel; just...@spectralogic.com
in v4:
- Turn to use 'ring-page-order' and 'max-ring-page-order'.
- A few comments from Roger.
Changes in v5:
- Clarify with 4k granularity to comment
- Address more comments from Roger
Signed-off-by: Bob Liu
---
drivers/block/xen-blkback/blkback.c | 13
drivers/block/xen-blkback
This is a pre-patch for multi-page ring feature.
In connect_ring, we can know exactly how many pages are used for the shared
ring, delay pending_req allocation here so that we won't waste too much memory.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkback/common.h |2 +-
drivers/block/xen
and
furthermore it would not allow frontend/backend to negotiate 'multi-page'
and 'multi-queue' features.
Changes in v2:
- Re-write the commit message to be more clear.
Signed-off-by: Bob Liu
Acked-by: Roger Pau Monné
---
drivers/block/xen-blkfront.c | 14 ++
1 file changed, 6 insertions(+), 8
and
furthermore it would not allow frontend/backend to negotiate 'multi-page'
and 'multi-queue' features.
Changes in v2:
- Re-write the commit message to be more clear.
Signed-off-by: Bob Liu bob@oracle.com
Acked-by: Roger Pau Monné roger@citrix.com
---
drivers/block/xen-blkfront.c | 14
in v4:
- Turn to use 'ring-page-order' and 'max-ring-page-order'.
- A few comments from Roger.
Changes in v5:
- Clarify with 4k granularity to comment
- Address more comments from Roger
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/blkback.c | 13
drivers
This is a pre-patch for multi-page ring feature.
In connect_ring, we can know exactly how many pages are used for the shared
ring, delay pending_req allocation here so that we won't waste too much memory.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/common.h |2
On 06/01/2015 04:36 PM, Roger Pau Monné wrote:
> El 26/05/15 a les 2.06, Bob Liu ha escrit:
>> In connect_ring, we can know exactly how many pages are used for the shared
>> ring and also whether feature-persistent is enabled, delay pending_req
>> allocation here so that we
On 06/01/2015 03:50 PM, Roger Pau Monné wrote:
> El 26/05/15 a les 2.11, Bob Liu ha escrit:
>> When migrate from !feature-persistent host to feature-persistent host, domU
>> still think new host/backend don't support persistent.
>> Dmesg like:
>> backed has not unmapp
On 06/01/2015 04:36 PM, Roger Pau Monné wrote:
El 26/05/15 a les 2.06, Bob Liu ha escrit:
In connect_ring, we can know exactly how many pages are used for the shared
ring and also whether feature-persistent is enabled, delay pending_req
allocation here so that we won't waste too much memory
On 06/01/2015 03:50 PM, Roger Pau Monné wrote:
El 26/05/15 a les 2.11, Bob Liu ha escrit:
When migrate from !feature-persistent host to feature-persistent host, domU
still think new host/backend don't support persistent.
Dmesg like:
backed has not unmapped grant: 839
backed has not unmapped
501 - 600 of 1668 matches
Mail list logo
