[PATCH] fs/io_uring.c: fix typo in comment

From: Chunxin Zang Change "sane" to "same" in a comment in io_uring.c Signed-off-by: Chunxin Zang --- fs/io_uring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/io_uring.c b/fs/io_uring.c index 1f68105a41ed..da86440130f9 100644 --- a/fs/io_uring.c +++ b/fs/io_uring.c

[PATCH] Documentation/scheduler: Modify the description of sched-stats column 9

From: Chunxin Zang The column 9 get datas from sched_info->pcount. It's update when context_switch only. So it meaning 'times' not 'timeslices'. Signed-off-by: Chunxin Zang --- Documentation/scheduler/sched-stats.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documenta

[PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2

From: Chunxin Zang In the cgroup v1, we have 'force_mepty' interface. This is very useful for userspace to actively release memory. But the cgroup v2 does not. This patch reuse cgroup v1's function, but have a new name for the interface. Because I think 'drop_cache' may be is easier to understan

[PATCH v5] mm/vmscan: add a fatal signals check in drop_slab_node

From: Chunxin Zang On our server, there are about 10k memcg in one machine. They use memory very frequently. We have observed that drop_caches can take a considerable amount of time, and can't stop it. There are two reasons: 1. There is somebody constantly generating more objects to reclaim on

[PATCH v3] mm/vmscan: add a fatal signals check in drop_slab_node

From: Chunxin Zang On our server, there are about 10k memcg in one machine. They use memory very frequently. We have observed that drop_caches can take a considerable amount of time, and can't stop it. There are two reasons: 1. There is somebody constantly generating more objects to reclaim o

[PATCH v4] mm/vmscan: add a fatal signals check in drop_slab_node

From: Chunxin Zang On our server, there are about 10k memcg in one machine. They use memory very frequently. We have observed that drop_caches can take a considerable amount of time, and can't stop it. There are two reasons: 1. There is somebody constantly generating more objects to reclaim o

[PATCH v2] mm/vmscan: fix infinite loop in drop_slab_node

From: Chunxin Zang On our server, there are about 10k memcg in one machine. They use memory very frequently. When I tigger drop caches，the process will infinite loop in drop_slab_node. There are two reasons: 1.We have too many memcgs, even though one object freed in one memcg, the sum of objec

[PATCH] mm/vmscan: fix infinite loop in drop_slab_node

From: Chunxin Zang On our server, there are about 10k memcg in one machine. They use memory very frequently. When I tigger drop caches，the process will infinite loop in drop_slab_node. There are two reasons: 1.We have too many memcgs, even though one object freed in one memcg, the sum of object