On 1/21/21 1:53 AM, Greg KH wrote:
X-Gm-Spam: 0
X-Gm-Phishy: 0
On Mon, Jan 18, 2021 at 09:42:57AM +0800, zhenwei pi wrote:
Hi, Greg
What's the next step I should take?
I need some reviews by the people who will be doing the qemu portion of
this, or someone else, please.
thanks,
greg k-h
Hi, Greg
What's the next step I should take?
On 1/10/21 7:53 PM, zhenwei pi wrote:
v4 -> v5:
Use sysfs_emit to export attribute value.
Only allow subset of capability to set on events.
Add more detailed infomation in document.
v3 -> v4:
Use event sysfs attribute instead of module par
in 0d3b6a8d213a), ka_work still has a chance to run
(called by nvmet_start_ctrl).
Fixes: 0d3b6a8d213a ("nvmet: Disable keep-alive timer when kato is cleared to
0h")
Signed-off-by: zhenwei pi
---
drivers/nvme/target/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dr
Currently if hitting block req error, block layer only prints error
log with a rate limitation. Then agent has to parse kernel log to
record what happens.
In this patch, add read/write/discard/flush stat counter to record
io errors.
Signed-off-by: zhenwei pi
---
block/blk-core.c | 14
.
Signed-off-by: zhenwei pi
---
drivers/nvme/target/configfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
index 37e1d7784e17..e7808a86ccef 100644
--- a/drivers/nvme/target/configfs.c
+++ b/drivers/nvme
side, and run 'nvme id-ctrl /dev/nvme0' on initiator side,
then we can get the same SN string.
Signed-off-by: zhenwei pi
Reported-by: kernel test robot
---
drivers/nvme/target/configfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/target/configfs.c b
received from target, and the
host side continues to process without length checking, then the
previous CQE is processed twice.
Handle data length, ignore zero bytes message, and try to recovery for
corrupted CQE case.
Thanks to Chao Leng for suggestions.
Signed-off-by: zhenwei pi
---
drivers/nvme
connections on transport layer is not
standard, currently still treat it as illegal.
Thanks to Chao Leng & Sagi for suggestions.
Signed-off-by: zhenwei pi
---
drivers/nvme/host/rdma.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c
i
Hi, Jens
What do you think about this, adding io error stat for block devices is
reasonable?
On 9/10/20 10:20 AM, zhenwei pi wrote:
Currently if hitting block req error, block layer only prints error
log with a rate limitation. Then agent has to parse kernel log to
record what happens
received from target, and the
host side continues to process without length checking, then the
previous CQE is processed twice.
Handle data length, ignore zero bytes message, and try to recovery for
corrupted CQE case.
Signed-off-by: zhenwei pi
---
drivers/nvme/host/rdma.c | 11 +++
1 file
On 10/22/20 5:55 PM, Chao Leng wrote:
On 2020/10/22 16:38, zhenwei pi wrote:
Hit a kernel warning:
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 0 at lib/refcount.c:28
RIP: 0010:refcount_warn_saturate+0xd9/0xe0
Call Trace:
nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma
In the zero KATO scenario, if initiator crashes without transport
layer disconnection, target side would never reclaim resources.
A target could start transport layer keep-alive to detect dead
connection for the admin queue.
Signed-off-by: zhenwei pi
---
drivers/nvme/target/admin-cmd.c | 2
Add tcp keep-alive to detect dead connections for zero KATO case.
Signed-off-by: zhenwei pi
---
drivers/nvme/target/tcp.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/nvme/target/tcp.c b/drivers/nvme/target/tcp.c
index dc1f0f647189..58800e914e61 100644
Hi, Jens
How do you think about error stat of a block device?
On 9/10/20 10:20 AM, zhenwei pi wrote:
Currently if hitting block req error, block layer only prints error
log with a rate limitation. Then agent has to parse kernel log to
record what happens.
In this patch, add read/write/discard
On 10/28/20 3:15 PM, Sagi Grimberg wrote:
On 10/27/20 5:15 AM, zhenwei pi wrote:
In the zero KATO scenario, if initiator crashes without transport
layer disconnection, target side would never reclaim resources.
A target could start transport layer keep-alive to detect dead
connection
in 0d3b6a8d213a), ka_work still has a chance to run
(called by nvmet_start_ctrl to detect dead host).
Initilize ka_work during allocating ctrl, and set a reasonable kato
before scheduling ka_work.
Signed-off-by: zhenwei pi
---
drivers/nvme/target/core.c | 16 +++-
1 file changed, 11
in 0d3b6a8d213a), ka_work still has a chance to run
(called by nvmet_start_ctrl).
Fixes:
Don't run keep alive work with zero kato.
Signed-off-by: zhenwei pi
---
drivers/nvme/target/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target
char *buf)
{
- return sysfs_emit(buf, "%x", events);
+ return sysfs_emit(buf, "%x\n", events);
}
static ssize_t events_store(struct device *dev, struct device_attribute *attr,
Hi, Greg is the maintainer of this driver.
--
zhenwei pi
On 2/3/21 10:57 PM, Greg Kroah-Hartman wrote:
On Mon, Feb 01, 2021 at 09:56:57AM +0800, zhenwei pi wrote:
On 1/30/21 3:08 AM, Joe Perches wrote:
Add newline terminations to the sysfs_emit uses added by -next
commit 8d6da6575ffe ("misc: pvpanic: introduce events device attribue")
CPUs still halt in idle.
We can config boot parameter in guest(Ex, 16vCPUs on x86) like this:
linux ... irqaffinity=0,2,4,6 nohlt_list=0,2,4,6
it means that 25% of CPUs can always run in vm-mode and benefit
from posted-interrupt.
Signed-off-by: zhenwei pi
---
kernel/sched/idle.c | 35
short desc for /proc/softirqs in this patch, then /proc/softirqs
gets more human-readable.
Signed-off-by: zhenwei pi
---
fs/proc/softirqs.c| 2 +-
include/linux/interrupt.h | 5 +++--
kernel/softirq.c | 12
3 files changed, 16 insertions(+), 3 deletions(-)
diff
sending event to host side, check capability firstly.
Suggested by Paolo, export capability of pvpanic device by read-only
module parameter.
Signed-off-by: zhenwei pi
---
drivers/misc/pvpanic.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/misc
sending event to host side, check capability firstly.
Suggested by Greg KH, use sysfs to expose capability to user space.
Signed-off-by: zhenwei pi
---
.../ABI/testing/sysfs-bus-pci-devices-pvpanic | 7
drivers/misc/pvpanic.c| 41 ---
2 files changed
before kicking
host side, check the event is supported or not.
zhenwei pi (2):
misc: pvpanic: introduce device capability
misc: pvpanic: introduce module parameter 'events'
drivers/misc/pvpanic.c | 45 --
1 file changed, 39 insertions(+), 6 deletions(-)
--
2.25.1
Suggested by Paolo, add a module parameter that can be used to limit
which capabilities the driver uses.
Finally, the pvpanic guest driver works by the limitation of both
device capability and user setting.
Signed-off-by: zhenwei pi
---
drivers/misc/pvpanic.c | 6 +-
1 file changed, 5
if this ever becomes not true, the module parameter is a mess...
thanks,
greg k-h
What about adding _two_ device attribute:
capability (0444): detect from device which the hypervisor really supports.
events (0644): root user could enable/disable feature(s) from guest side.
--
zhenwei pi
2:
Remove device info log, use module parameter to expose capability.
v1:
The guest sides determines pvpanic capability by RDPT, before kicking
host side, check the event is supported or not.
zhenwei pi (2):
misc: pvpanic: introduce device capability
misc: pvpanic: introduce module paramete
sending event to host side, check capability firstly.
Suggested by Greg KH, use sysfs to expose capability to user space,
also add new sysfs attribute in document.
Signed-off-by: zhenwei pi
---
.../ABI/testing/sysfs-bus-pci-devices-pvpanic | 7
drivers/misc/pvpanic.c
Suggested by Paolo & Greg, add 'events' device attribute that can be
used to limit which capabilities the driver uses.
Finally, the pvpanic guest driver works by the limitation of both
device capability and user setting.
Signed-off-by: zhenwei pi
---
.../ABI/testing/sysfs-bus-pci-dev
sending event to host side, check capability firstly.
Suggested by Greg KH, use sysfs to expose capability to user space,
also add new sysfs attribute in document.
Signed-off-by: zhenwei pi
---
.../ABI/testing/sysfs-bus-pci-devices-pvpanic | 12 +++
drivers/misc/pvpanic.c
Suggested by Paolo & Greg, add 'events' device attribute that can be
used to limit which capabilities the driver uses.
Finally, the pvpanic guest driver works by the limitation of both
device capability and user setting.
Signed-off-by: zhenwei pi
---
.../ABI/testing/sysfs-bus-pci-dev
side, check the event is supported or not.
zhenwei pi (2):
misc: pvpanic: introduce device capability
misc: pvpanic: introduce module parameter 'events'
.../ABI/testing/sysfs-bus-pci-devices-pvpanic | 14 +
drivers/misc/pvpanic.c| 58 +--
2 files
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 8
include/uapi/linux/virtio_balloon.h | 6
more memory, but it can't. Once more memory is required in
future, it will struggle to reclaim memory.
Acked-by: David Hildenbrand
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 9 +
include/uapi/linux/virtio_balloon.h | 12 ++--
2 files changed, 19
On 4/22/24 15:47, David Hildenbrand wrote:
On 22.04.24 09:42, zhenwei pi wrote:
All the VM events related statistics have dependence on
'CONFIG_VM_EVENT_COUNTERS', once any stack variable is required by any
VM events in future, we would have codes like:
#ifdef CONFIG_VM_EVENT_COUNTERS
grep for magic words in guest kernel log from host
side. Rather than this unstable way, virtio balloon reports OOM-KILL
invocations instead.
Acked-by: David Hildenbrand
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 1 +
include/uapi/linux/virtio_balloon.h | 6 --
2
-> v1:
- several text changes: oom-kill -> oom-kills, SCAN_ASYNC -> ASYN_SCAN.
- move vm events codes into '#ifdef CONFIG_VM_EVENT_COUNTERS'
RFC version:
Link:
https://lore.kernel.org/lkml/20240415084113.1203428-1-pizhen...@bytedance.com/T/#m1898963b3c27a989b1123db475135c3ca687ca84
= events[XXX] + events[YYY];
update_stat(vb, idx++, VIRTIO_BALLOON_S_XXX, foo);
#endif
Separate vm events into a single function, also remove
'CONFIG_VM_EVENT_COUNTERS' from 'update_balloon_stats'.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 44
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Acked-by: David Hildenbrand
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 8
include/uapi
more memory, but it can't. Once more memory is required in
future, it will struggle to reclaim memory.
Acked-by: David Hildenbrand
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 9 +
include/uapi/linux/virtio_balloon.h | 12 ++--
2 files changed, 19
grep for magic words in guest kernel log from host
side. Rather than this unstable way, virtio balloon reports OOM-KILL
invocations instead.
Acked-by: David Hildenbrand
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 1 +
include/uapi/linux/virtio_balloon.h | 6 --
2
All the VM events related statistics have dependence on
'CONFIG_VM_EVENT_COUNTERS', separate these events into a function to
make code clean. Then we can remove 'CONFIG_VM_EVENT_COUNTERS' from
'update_balloon_stats'.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 43
re.kernel.org/lkml/20240415084113.1203428-1-pizhen...@bytedance.com/T/#m1898963b3c27a989b1123db475135c3ca687ca84
zhenwei pi (4):
virtio_balloon: separate vm events into a function
virtio_balloon: introduce oom-kill invocations
virtio_balloon: introduce memory allocation stall counter
virtio_
On 4/15/24 23:01, David Hildenbrand wrote:
On 15.04.24 10:41, zhenwei pi wrote:
Hi,
When the guest runs under critial memory pressure, the guest becomss
too slow, even sshd turns D state(uninterruptible) on memory
allocation. We can't login this VM to do any work on trouble shooting.
Guest
more memory, but it can't. Once more memory is required in
future, it will struggle to reclaim memory.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 9 +
include/uapi/linux/virtio_balloon.h | 12 ++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 19 ++-
include/uapi/linux
grep for magic words in guest kernel log from host
side. Rather than this unstable way, virtio balloon reports OOM-KILL
invocations instead.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 2 ++
include/uapi/linux/virtio_balloon.h | 6 --
2 files changed, 6 insertions
more memory is required in
future, it will struggle to reclaim memory.
zhenwei pi (3):
virtio_balloon: introduce oom-kill invocations
virtio_balloon: introduce memory allocation stall counter
virtio_balloon: introduce memory scan/reclaim info
drivers/virtio/virtio_balloon.c | 30
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 20 +++-
include/uapi/linux
RFC -> v1:
- several text changes: oom-kill -> oom-kills, SCAN_ASYNC -> ASYN_SCAN.
- move vm events codes into '#ifdef CONFIG_VM_EVENT_COUNTERS'
RFC version:
Link:
https://lore.kernel.org/lkml/20240415084113.1203428-1-pizhen...@bytedance.com/T/#m1898963b3c27a989b1123db475135c3ca687ca84
grep for magic words in guest kernel log from host
side. Rather than this unstable way, virtio balloon reports OOM-KILL
invocations instead.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 1 +
include/uapi/linux/virtio_balloon.h | 6 --
2 files changed, 5 insertions(+), 2
more memory, but it can't. Once more memory is required in
future, it will struggle to reclaim memory.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 9 +
include/uapi/linux/virtio_balloon.h | 12 ++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff
On 4/23/24 17:13, Michael S. Tsirkin wrote:
On Tue, Apr 23, 2024 at 11:41:07AM +0800, zhenwei pi wrote:
[snip]
#define VIRTIO_BALLOON_S_NAMES_WITH_PREFIX(VIRTIO_BALLOON_S_NAMES_prefix) { \
VIRTIO_BALLOON_S_NAMES_prefix "swap-in", \
Looks like a useful extension. Bu
53 matches
Mail list logo
