From: Wei Wang <wei.w.wang@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-mm@kvack.org, mst@redhat.com,
mhocko@kernel.org, akpm@linux-foundation.org,
mawilcox@microsoft.com
Cc: david@redhat.com, cornelia.huck@de.ibm.com,
mgorman@techsingularity.net, aarcange@redhat.com,
amit.shah@redhat.com, pbonzini@redhat.com, willy@infradead.org,
liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
quan.xu@aliyun.com, nilal@redhat.com, riel@redhat.com
Subject: [virtio-dev] Re: [PATCH v19 3/7] xbitmap: add more operations
Date: Wed, 13 Dec 2017 20:26:06 +0800 [thread overview]
Message-ID: <5A311C5E.7000304@intel.com> (raw)
In-Reply-To: <201712122220.IFH05261.LtJOFFSFHVMQOO@I-love.SAKURA.ne.jp>
On 12/12/2017 09:20 PM, Tetsuo Handa wrote:
> Wei Wang wrote:
>> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long end)
>> +{
>> + struct radix_tree_root *root = &xb->xbrt;
>> + struct radix_tree_node *node;
>> + void **slot;
>> + struct ida_bitmap *bitmap;
>> + unsigned int nbits;
>> +
>> + for (; start < end; start = (start | (IDA_BITMAP_BITS - 1)) + 1) {
>> + unsigned long index = start / IDA_BITMAP_BITS;
>> + unsigned long bit = start % IDA_BITMAP_BITS;
>> +
>> + bitmap = __radix_tree_lookup(root, index, &node, &slot);
>> + if (radix_tree_exception(bitmap)) {
>> + unsigned long ebit = bit + 2;
>> + unsigned long tmp = (unsigned long)bitmap;
>> +
>> + nbits = min(end - start + 1, BITS_PER_LONG - ebit);
>> +
>> + if (ebit >= BITS_PER_LONG)
> What happens if we hit this "continue;" when "index == ULONG_MAX / IDA_BITMAP_BITS" ?
Thanks. I also improved the test case for this. I plan to change the
implementation a little bit to avoid such overflow (has passed the test
case that I have, just post out for another set of eyes):
{
...
unsigned long idx = start / IDA_BITMAP_BITS;
unsigned long bit = start % IDA_BITMAP_BITS;
unsigned long idx_end = end / IDA_BITMAP_BITS;
unsigned long ret;
for (idx = start / IDA_BITMAP_BITS; idx <= idx_end; idx++) {
unsigned long ida_start = idx * IDA_BITMAP_BITS;
bitmap = __radix_tree_lookup(root, idx, &node, &slot);
if (radix_tree_exception(bitmap)) {
unsigned long tmp = (unsigned long)bitmap;
unsigned long ebit = bit + 2;
if (ebit >= BITS_PER_LONG)
continue;
if (set)
ret = find_next_bit(&tmp,
BITS_PER_LONG, ebit);
else
ret = find_next_zero_bit(&tmp,
BITS_PER_LONG,
ebit);
if (ret < BITS_PER_LONG)
return ret - 2 + ida_start;
} else if (bitmap) {
if (set)
ret = find_next_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
else
ret = find_next_zero_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
if (ret < IDA_BITMAP_BITS)
return ret + ida_start;
} else if (!bitmap && !set) {
return bit + IDA_BITMAP_BITS * idx;
}
bit = 0;
}
return end;
}
>
> Can you eliminate exception path and fold all xbitmap patches into one, and
> post only one xbitmap patch without virtio-baloon changes? If exception path
> is valuable, you can add exception path after minimum version is merged.
> This series is too difficult for me to close corner cases.
That exception path is claimed to save memory, and I don't have a strong
reason to remove that part.
Matthew, could we get your feedback on this?
>
>> +/**
>> + * xb_find_next_set_bit - find the next set bit in a range
>> + * @xb: the xbitmap to search
>> + * @start: the start of the range, inclusive
>> + * @end: the end of the range, exclusive
>> + *
>> + * Returns: the index of the found bit, or @end + 1 if no such bit is found.
>> + */
>> +unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start,
>> + unsigned long end)
>> +{
>> + return xb_find_next_bit(xb, start, end, 1);
>> +}
> Won't "exclusive" loose ability to handle ULONG_MAX ? Since this is a
> library module, missing ability to handle ULONG_MAX sounds like an omission.
> Shouldn't we pass (or return) whether "found or not" flag (e.g. strtoul() in
> C library function)?
>
> bool xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, unsigned long *result);
> unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, bool *found);
Yes, ULONG_MAX needs to be tested by xb_test_bit(). Compared to checking
the return value, would it be the same to let the caller check for the
ULONG_MAX boundary?
Best,
Wei
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
WARNING: multiple messages have this Message-ID (diff)
From: Wei Wang <wei.w.wang@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-mm@kvack.org, mst@redhat.com,
mhocko@kernel.org, akpm@linux-foundation.org,
mawilcox@microsoft.com
Cc: david@redhat.com, cornelia.huck@de.ibm.com,
mgorman@techsingularity.net, aarcange@redhat.com,
amit.shah@redhat.com, pbonzini@redhat.com, willy@infradead.org,
liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
quan.xu@aliyun.com, nilal@redhat.com, riel@redhat.com
Subject: Re: [PATCH v19 3/7] xbitmap: add more operations
Date: Wed, 13 Dec 2017 20:26:06 +0800 [thread overview]
Message-ID: <5A311C5E.7000304@intel.com> (raw)
In-Reply-To: <201712122220.IFH05261.LtJOFFSFHVMQOO@I-love.SAKURA.ne.jp>
On 12/12/2017 09:20 PM, Tetsuo Handa wrote:
> Wei Wang wrote:
>> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long end)
>> +{
>> + struct radix_tree_root *root = &xb->xbrt;
>> + struct radix_tree_node *node;
>> + void **slot;
>> + struct ida_bitmap *bitmap;
>> + unsigned int nbits;
>> +
>> + for (; start < end; start = (start | (IDA_BITMAP_BITS - 1)) + 1) {
>> + unsigned long index = start / IDA_BITMAP_BITS;
>> + unsigned long bit = start % IDA_BITMAP_BITS;
>> +
>> + bitmap = __radix_tree_lookup(root, index, &node, &slot);
>> + if (radix_tree_exception(bitmap)) {
>> + unsigned long ebit = bit + 2;
>> + unsigned long tmp = (unsigned long)bitmap;
>> +
>> + nbits = min(end - start + 1, BITS_PER_LONG - ebit);
>> +
>> + if (ebit >= BITS_PER_LONG)
> What happens if we hit this "continue;" when "index == ULONG_MAX / IDA_BITMAP_BITS" ?
Thanks. I also improved the test case for this. I plan to change the
implementation a little bit to avoid such overflow (has passed the test
case that I have, just post out for another set of eyes):
{
...
unsigned long idx = start / IDA_BITMAP_BITS;
unsigned long bit = start % IDA_BITMAP_BITS;
unsigned long idx_end = end / IDA_BITMAP_BITS;
unsigned long ret;
for (idx = start / IDA_BITMAP_BITS; idx <= idx_end; idx++) {
unsigned long ida_start = idx * IDA_BITMAP_BITS;
bitmap = __radix_tree_lookup(root, idx, &node, &slot);
if (radix_tree_exception(bitmap)) {
unsigned long tmp = (unsigned long)bitmap;
unsigned long ebit = bit + 2;
if (ebit >= BITS_PER_LONG)
continue;
if (set)
ret = find_next_bit(&tmp,
BITS_PER_LONG, ebit);
else
ret = find_next_zero_bit(&tmp,
BITS_PER_LONG,
ebit);
if (ret < BITS_PER_LONG)
return ret - 2 + ida_start;
} else if (bitmap) {
if (set)
ret = find_next_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
else
ret = find_next_zero_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
if (ret < IDA_BITMAP_BITS)
return ret + ida_start;
} else if (!bitmap && !set) {
return bit + IDA_BITMAP_BITS * idx;
}
bit = 0;
}
return end;
}
>
> Can you eliminate exception path and fold all xbitmap patches into one, and
> post only one xbitmap patch without virtio-baloon changes? If exception path
> is valuable, you can add exception path after minimum version is merged.
> This series is too difficult for me to close corner cases.
That exception path is claimed to save memory, and I don't have a strong
reason to remove that part.
Matthew, could we get your feedback on this?
>
>> +/**
>> + * xb_find_next_set_bit - find the next set bit in a range
>> + * @xb: the xbitmap to search
>> + * @start: the start of the range, inclusive
>> + * @end: the end of the range, exclusive
>> + *
>> + * Returns: the index of the found bit, or @end + 1 if no such bit is found.
>> + */
>> +unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start,
>> + unsigned long end)
>> +{
>> + return xb_find_next_bit(xb, start, end, 1);
>> +}
> Won't "exclusive" loose ability to handle ULONG_MAX ? Since this is a
> library module, missing ability to handle ULONG_MAX sounds like an omission.
> Shouldn't we pass (or return) whether "found or not" flag (e.g. strtoul() in
> C library function)?
>
> bool xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, unsigned long *result);
> unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, bool *found);
Yes, ULONG_MAX needs to be tested by xb_test_bit(). Compared to checking
the return value, would it be the same to let the caller check for the
ULONG_MAX boundary?
Best,
Wei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Wei Wang <wei.w.wang@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-mm@kvack.org, mst@redhat.com,
mhocko@kernel.org, akpm@linux-foundation.org,
mawilcox@microsoft.com
Cc: david@redhat.com, cornelia.huck@de.ibm.com,
mgorman@techsingularity.net, aarcange@redhat.com,
amit.shah@redhat.com, pbonzini@redhat.com, willy@infradead.org,
liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
quan.xu@aliyun.com, nilal@redhat.com, riel@redhat.com
Subject: Re: [PATCH v19 3/7] xbitmap: add more operations
Date: Wed, 13 Dec 2017 20:26:06 +0800 [thread overview]
Message-ID: <5A311C5E.7000304@intel.com> (raw)
In-Reply-To: <201712122220.IFH05261.LtJOFFSFHVMQOO@I-love.SAKURA.ne.jp>
On 12/12/2017 09:20 PM, Tetsuo Handa wrote:
> Wei Wang wrote:
>> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long end)
>> +{
>> + struct radix_tree_root *root = &xb->xbrt;
>> + struct radix_tree_node *node;
>> + void **slot;
>> + struct ida_bitmap *bitmap;
>> + unsigned int nbits;
>> +
>> + for (; start < end; start = (start | (IDA_BITMAP_BITS - 1)) + 1) {
>> + unsigned long index = start / IDA_BITMAP_BITS;
>> + unsigned long bit = start % IDA_BITMAP_BITS;
>> +
>> + bitmap = __radix_tree_lookup(root, index, &node, &slot);
>> + if (radix_tree_exception(bitmap)) {
>> + unsigned long ebit = bit + 2;
>> + unsigned long tmp = (unsigned long)bitmap;
>> +
>> + nbits = min(end - start + 1, BITS_PER_LONG - ebit);
>> +
>> + if (ebit >= BITS_PER_LONG)
> What happens if we hit this "continue;" when "index == ULONG_MAX / IDA_BITMAP_BITS" ?
Thanks. I also improved the test case for this. I plan to change the
implementation a little bit to avoid such overflow (has passed the test
case that I have, just post out for another set of eyes):
{
...
unsigned long idx = start / IDA_BITMAP_BITS;
unsigned long bit = start % IDA_BITMAP_BITS;
unsigned long idx_end = end / IDA_BITMAP_BITS;
unsigned long ret;
for (idx = start / IDA_BITMAP_BITS; idx <= idx_end; idx++) {
unsigned long ida_start = idx * IDA_BITMAP_BITS;
bitmap = __radix_tree_lookup(root, idx, &node, &slot);
if (radix_tree_exception(bitmap)) {
unsigned long tmp = (unsigned long)bitmap;
unsigned long ebit = bit + 2;
if (ebit >= BITS_PER_LONG)
continue;
if (set)
ret = find_next_bit(&tmp,
BITS_PER_LONG, ebit);
else
ret = find_next_zero_bit(&tmp,
BITS_PER_LONG,
ebit);
if (ret < BITS_PER_LONG)
return ret - 2 + ida_start;
} else if (bitmap) {
if (set)
ret = find_next_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
else
ret = find_next_zero_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
if (ret < IDA_BITMAP_BITS)
return ret + ida_start;
} else if (!bitmap && !set) {
return bit + IDA_BITMAP_BITS * idx;
}
bit = 0;
}
return end;
}
>
> Can you eliminate exception path and fold all xbitmap patches into one, and
> post only one xbitmap patch without virtio-baloon changes? If exception path
> is valuable, you can add exception path after minimum version is merged.
> This series is too difficult for me to close corner cases.
That exception path is claimed to save memory, and I don't have a strong
reason to remove that part.
Matthew, could we get your feedback on this?
>
>> +/**
>> + * xb_find_next_set_bit - find the next set bit in a range
>> + * @xb: the xbitmap to search
>> + * @start: the start of the range, inclusive
>> + * @end: the end of the range, exclusive
>> + *
>> + * Returns: the index of the found bit, or @end + 1 if no such bit is found.
>> + */
>> +unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start,
>> + unsigned long end)
>> +{
>> + return xb_find_next_bit(xb, start, end, 1);
>> +}
> Won't "exclusive" loose ability to handle ULONG_MAX ? Since this is a
> library module, missing ability to handle ULONG_MAX sounds like an omission.
> Shouldn't we pass (or return) whether "found or not" flag (e.g. strtoul() in
> C library function)?
>
> bool xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, unsigned long *result);
> unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, bool *found);
Yes, ULONG_MAX needs to be tested by xb_test_bit(). Compared to checking
the return value, would it be the same to let the caller check for the
ULONG_MAX boundary?
Best,
Wei
WARNING: multiple messages have this Message-ID (diff)
From: Wei Wang <wei.w.wang@intel.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
kvm@vger.kernel.org, linux-mm@kvack.org, mst@redhat.com,
mhocko@kernel.org, akpm@linux-foundation.org,
mawilcox@microsoft.com
Cc: david@redhat.com, cornelia.huck@de.ibm.com,
mgorman@techsingularity.net, aarcange@redhat.com,
amit.shah@redhat.com, pbonzini@redhat.com, willy@infradead.org,
liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
quan.xu@aliyun.com, nilal@redhat.com, riel@redhat.com
Subject: Re: [Qemu-devel] [PATCH v19 3/7] xbitmap: add more operations
Date: Wed, 13 Dec 2017 20:26:06 +0800 [thread overview]
Message-ID: <5A311C5E.7000304@intel.com> (raw)
In-Reply-To: <201712122220.IFH05261.LtJOFFSFHVMQOO@I-love.SAKURA.ne.jp>
On 12/12/2017 09:20 PM, Tetsuo Handa wrote:
> Wei Wang wrote:
>> +void xb_clear_bit_range(struct xb *xb, unsigned long start, unsigned long end)
>> +{
>> + struct radix_tree_root *root = &xb->xbrt;
>> + struct radix_tree_node *node;
>> + void **slot;
>> + struct ida_bitmap *bitmap;
>> + unsigned int nbits;
>> +
>> + for (; start < end; start = (start | (IDA_BITMAP_BITS - 1)) + 1) {
>> + unsigned long index = start / IDA_BITMAP_BITS;
>> + unsigned long bit = start % IDA_BITMAP_BITS;
>> +
>> + bitmap = __radix_tree_lookup(root, index, &node, &slot);
>> + if (radix_tree_exception(bitmap)) {
>> + unsigned long ebit = bit + 2;
>> + unsigned long tmp = (unsigned long)bitmap;
>> +
>> + nbits = min(end - start + 1, BITS_PER_LONG - ebit);
>> +
>> + if (ebit >= BITS_PER_LONG)
> What happens if we hit this "continue;" when "index == ULONG_MAX / IDA_BITMAP_BITS" ?
Thanks. I also improved the test case for this. I plan to change the
implementation a little bit to avoid such overflow (has passed the test
case that I have, just post out for another set of eyes):
{
...
unsigned long idx = start / IDA_BITMAP_BITS;
unsigned long bit = start % IDA_BITMAP_BITS;
unsigned long idx_end = end / IDA_BITMAP_BITS;
unsigned long ret;
for (idx = start / IDA_BITMAP_BITS; idx <= idx_end; idx++) {
unsigned long ida_start = idx * IDA_BITMAP_BITS;
bitmap = __radix_tree_lookup(root, idx, &node, &slot);
if (radix_tree_exception(bitmap)) {
unsigned long tmp = (unsigned long)bitmap;
unsigned long ebit = bit + 2;
if (ebit >= BITS_PER_LONG)
continue;
if (set)
ret = find_next_bit(&tmp,
BITS_PER_LONG, ebit);
else
ret = find_next_zero_bit(&tmp,
BITS_PER_LONG,
ebit);
if (ret < BITS_PER_LONG)
return ret - 2 + ida_start;
} else if (bitmap) {
if (set)
ret = find_next_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
else
ret = find_next_zero_bit(bitmap->bitmap,
IDA_BITMAP_BITS, bit);
if (ret < IDA_BITMAP_BITS)
return ret + ida_start;
} else if (!bitmap && !set) {
return bit + IDA_BITMAP_BITS * idx;
}
bit = 0;
}
return end;
}
>
> Can you eliminate exception path and fold all xbitmap patches into one, and
> post only one xbitmap patch without virtio-baloon changes? If exception path
> is valuable, you can add exception path after minimum version is merged.
> This series is too difficult for me to close corner cases.
That exception path is claimed to save memory, and I don't have a strong
reason to remove that part.
Matthew, could we get your feedback on this?
>
>> +/**
>> + * xb_find_next_set_bit - find the next set bit in a range
>> + * @xb: the xbitmap to search
>> + * @start: the start of the range, inclusive
>> + * @end: the end of the range, exclusive
>> + *
>> + * Returns: the index of the found bit, or @end + 1 if no such bit is found.
>> + */
>> +unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start,
>> + unsigned long end)
>> +{
>> + return xb_find_next_bit(xb, start, end, 1);
>> +}
> Won't "exclusive" loose ability to handle ULONG_MAX ? Since this is a
> library module, missing ability to handle ULONG_MAX sounds like an omission.
> Shouldn't we pass (or return) whether "found or not" flag (e.g. strtoul() in
> C library function)?
>
> bool xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, unsigned long *result);
> unsigned long xb_find_next_set_bit(struct xb *xb, unsigned long start, unsigned long end, bool *found);
Yes, ULONG_MAX needs to be tested by xb_test_bit(). Compared to checking
the return value, would it be the same to let the caller check for the
ULONG_MAX boundary?
Best,
Wei
next prev parent reply other threads:[~2017-12-13 12:24 UTC|newest]
Thread overview: 179+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-12 11:55 [virtio-dev] [PATCH v19 0/7] Virtio-balloon Enhancement Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` [PATCH v19 1/7] xbitmap: Introduce xbitmap Wei Wang
2017-12-12 11:55 ` [virtio-dev] " Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 12:53 ` Philippe Ombredanne
2017-12-12 12:53 ` [Qemu-devel] " Philippe Ombredanne
2017-12-12 12:53 ` Philippe Ombredanne
2017-12-12 12:53 ` Philippe Ombredanne
2017-12-15 11:05 ` kbuild test robot
2017-12-15 11:05 ` [Qemu-devel] " kbuild test robot
2017-12-15 11:05 ` kbuild test robot
2017-12-15 13:24 ` Matthew Wilcox
2017-12-15 13:24 ` Matthew Wilcox
2017-12-15 13:24 ` [Qemu-devel] " Matthew Wilcox
2017-12-15 13:24 ` Matthew Wilcox
2017-12-16 10:10 ` [virtio-dev] " Wei Wang
2017-12-16 10:10 ` [Qemu-devel] " Wei Wang
2017-12-16 10:10 ` Wei Wang
2017-12-16 10:10 ` Wei Wang
2017-12-16 10:10 ` Wei Wang
2017-12-15 11:05 ` kbuild test robot
2017-12-12 11:55 ` [virtio-dev] [PATCH v19 2/7] xbitmap: potential improvement Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-15 3:07 ` kbuild test robot
2017-12-15 3:07 ` [Qemu-devel] " kbuild test robot
2017-12-15 3:07 ` kbuild test robot
2017-12-15 3:07 ` kbuild test robot
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` [virtio-dev] [PATCH v19 3/7] xbitmap: add more operations Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 13:20 ` Tetsuo Handa
2017-12-12 13:20 ` [Qemu-devel] " Tetsuo Handa
2017-12-12 13:20 ` Tetsuo Handa
2017-12-13 12:26 ` Wei Wang
2017-12-13 12:26 ` Wei Wang [this message]
2017-12-13 12:26 ` [Qemu-devel] " Wei Wang
2017-12-13 12:26 ` Wei Wang
2017-12-13 12:26 ` Wei Wang
2017-12-13 14:16 ` Tetsuo Handa
2017-12-13 14:16 ` [Qemu-devel] " Tetsuo Handa
2017-12-13 14:16 ` Tetsuo Handa
2017-12-14 3:47 ` [virtio-dev] " Wei Wang
2017-12-14 3:47 ` [Qemu-devel] " Wei Wang
2017-12-14 3:47 ` Wei Wang
2017-12-14 3:47 ` Wei Wang
2017-12-14 11:47 ` [virtio-dev] " Wei Wang
2017-12-14 11:47 ` [Qemu-devel] " Wei Wang
2017-12-14 11:47 ` Wei Wang
2017-12-14 11:47 ` Wei Wang
2017-12-14 11:47 ` Wei Wang
2017-12-14 16:29 ` Tetsuo Handa
2017-12-14 16:29 ` [Qemu-devel] " Tetsuo Handa
2017-12-14 16:29 ` Tetsuo Handa
2017-12-14 18:12 ` Matthew Wilcox
2017-12-14 18:12 ` [Qemu-devel] " Matthew Wilcox
2017-12-14 18:12 ` Matthew Wilcox
2017-12-15 16:21 ` Tetsuo Handa
2017-12-15 16:21 ` [Qemu-devel] " Tetsuo Handa
2017-12-15 16:21 ` Tetsuo Handa
2017-12-15 18:26 ` Michael S. Tsirkin
2017-12-15 18:26 ` [virtio-dev] " Michael S. Tsirkin
2017-12-15 18:26 ` [Qemu-devel] " Michael S. Tsirkin
2017-12-15 18:26 ` Michael S. Tsirkin
2017-12-15 18:26 ` Michael S. Tsirkin
2017-12-16 4:31 ` Tetsuo Handa
2017-12-16 4:31 ` [Qemu-devel] " Tetsuo Handa
2017-12-16 4:31 ` Tetsuo Handa
2017-12-16 5:05 ` Matthew Wilcox
2017-12-16 5:05 ` Matthew Wilcox
2017-12-16 5:05 ` [Qemu-devel] " Matthew Wilcox
2017-12-16 5:05 ` Matthew Wilcox
2017-12-16 5:57 ` Tetsuo Handa
2017-12-16 5:57 ` [Qemu-devel] " Tetsuo Handa
2017-12-16 5:57 ` Tetsuo Handa
2017-12-15 18:49 ` Matthew Wilcox
2017-12-15 18:49 ` Matthew Wilcox
2017-12-15 18:49 ` [Qemu-devel] " Matthew Wilcox
2017-12-15 18:49 ` Matthew Wilcox
2017-12-15 19:22 ` Matthew Wilcox
2017-12-15 19:22 ` Matthew Wilcox
2017-12-15 19:22 ` [Qemu-devel] " Matthew Wilcox
2017-12-15 19:22 ` Matthew Wilcox
2017-12-17 13:47 ` [virtio-dev] " Wang, Wei W
2017-12-17 13:47 ` [Qemu-devel] " Wang, Wei W
2017-12-17 13:47 ` Wang, Wei W
2017-12-17 13:47 ` Wang, Wei W
2017-12-17 13:47 ` Wang, Wei W
2017-12-17 22:18 ` Matthew Wilcox
2017-12-17 22:18 ` Matthew Wilcox
2017-12-17 22:18 ` [Qemu-devel] " Matthew Wilcox
2017-12-17 22:18 ` Matthew Wilcox
2017-12-17 22:18 ` Matthew Wilcox
2017-12-18 2:33 ` [virtio-dev] " Wei Wang
2017-12-18 2:33 ` [Qemu-devel] " Wei Wang
2017-12-18 2:33 ` Wei Wang
2017-12-18 2:33 ` Wei Wang
2017-12-18 2:33 ` Wei Wang
2017-12-18 2:59 ` Matthew Wilcox
2017-12-18 2:59 ` Matthew Wilcox
2017-12-18 2:59 ` [Qemu-devel] " Matthew Wilcox
2017-12-18 2:59 ` Matthew Wilcox
2017-12-18 2:59 ` Matthew Wilcox
2017-12-18 2:33 ` Wei Wang
2017-12-17 13:47 ` Wang, Wei W
2017-12-14 18:12 ` Matthew Wilcox
2017-12-16 10:14 ` Wei Wang
2017-12-16 10:14 ` [virtio-dev] " Wei Wang
2017-12-16 10:14 ` [Qemu-devel] " Wei Wang
2017-12-16 10:14 ` Wei Wang
2017-12-16 10:14 ` Wei Wang
2017-12-14 3:47 ` Wei Wang
2017-12-14 12:37 ` Matthew Wilcox
2017-12-14 12:37 ` [Qemu-devel] " Matthew Wilcox
2017-12-14 12:37 ` Matthew Wilcox
2017-12-14 12:37 ` Matthew Wilcox
2017-12-15 18:42 ` Matthew Wilcox
2017-12-15 18:42 ` [Qemu-devel] " Matthew Wilcox
2017-12-15 18:42 ` Matthew Wilcox
2017-12-16 10:12 ` [virtio-dev] " Wei Wang
2017-12-16 10:12 ` [Qemu-devel] " Wei Wang
2017-12-16 10:12 ` Wei Wang
2017-12-16 10:12 ` Wei Wang
2017-12-16 11:28 ` Tetsuo Handa
2017-12-16 11:28 ` [Qemu-devel] " Tetsuo Handa
2017-12-16 11:28 ` Tetsuo Handa
2017-12-17 5:24 ` [virtio-dev] " Wei Wang
2017-12-17 5:24 ` [Qemu-devel] " Wei Wang
2017-12-17 5:24 ` Wei Wang
2017-12-17 5:24 ` Wei Wang
2017-12-17 10:21 ` Tetsuo Handa
2017-12-17 10:21 ` [Qemu-devel] " Tetsuo Handa
2017-12-17 10:21 ` Tetsuo Handa
2017-12-17 11:50 ` [virtio-dev] " Wang, Wei W
2017-12-17 11:50 ` [Qemu-devel] " Wang, Wei W
2017-12-17 11:50 ` Wang, Wei W
2017-12-17 11:50 ` Wang, Wei W
2017-12-17 11:50 ` Wang, Wei W
2017-12-17 15:16 ` Tetsuo Handa
2017-12-17 15:16 ` [Qemu-devel] " Tetsuo Handa
2017-12-17 15:16 ` Tetsuo Handa
2017-12-18 8:05 ` [virtio-dev] " Wei Wang
2017-12-18 8:05 ` [Qemu-devel] " Wei Wang
2017-12-18 8:05 ` Wei Wang
2017-12-18 8:05 ` Wei Wang
2017-12-18 8:05 ` Wei Wang
2017-12-17 11:50 ` Wang, Wei W
2017-12-17 5:24 ` Wei Wang
2017-12-16 10:12 ` Wei Wang
2017-12-15 18:42 ` Matthew Wilcox
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` [PATCH v19 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG Wei Wang
2017-12-12 11:55 ` [virtio-dev] " Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` [PATCH v19 5/7] mm: support reporting free page blocks Wei Wang
2017-12-12 11:55 ` [virtio-dev] " Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` [virtio-dev] [PATCH v19 6/7] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` [PATCH v19 7/7] virtio-balloon: don't report free pages when page poisoning is enabled Wei Wang
2017-12-12 11:55 ` [virtio-dev] " Wei Wang
2017-12-12 11:55 ` [Qemu-devel] " Wei Wang
2017-12-12 11:55 ` Wei Wang
2017-12-12 11:55 ` Wei Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5A311C5E.7000304@intel.com \
--to=wei.w.wang@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=amit.shah@redhat.com \
--cc=cornelia.huck@de.ibm.com \
--cc=david@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=liliang.opensource@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mawilcox@microsoft.com \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=mst@redhat.com \
--cc=nilal@redhat.com \
--cc=pbonzini@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=qemu-devel@nongnu.org \
--cc=quan.xu@aliyun.com \
--cc=riel@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=willy@infradead.org \
--cc=yang.zhang.wz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.