Re: [PATCH] brd: expose number of allocated pages in debugfs

On Fri, Apr 16, 2021 at 02:18:29PM -0700, Saravanan D wrote: > From: Calvin Owens > > While the maximum size of each ramdisk is defined either > as a module parameter, or compile time default, it's impossible > to know how many pages have currently been allocated by each > r

[PATCH] brd: expose number of allocated pages in debugfs

cleaned up the !CONFIG_DEBUG_FS case and API changes for HEAD] Signed-off-by: Kyle McMartin [rebased] Signed-off-by: Saravanan D --- drivers/block/brd.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/block/brd.c b/drivers/block/brd.c index 18

[PATCH] blk-mq: Fix spurious debugfs directory creation during initialization

device_add_disk()->blk_register_queue()->blk_mq_debugfs_register() ->blk_mq_debugfs_register_hctx() later in the block device initialization sequence. A simple check for debugfs_dir has been added to thwart premature debugfs directory/file creation attempts. Signed-off-by: Saravanan D --- b

[PATCH V6] x86/mm: Tracking linear mapping split events

'tracepoint:raw_syscalls:sys_enter { @ [pid, comm] = count(); }' cat /proc/vmstat | grep -i direct_map_level direct_map_level2_splits 789 direct_map_level3_splits 12 Signed-off-by: Saravanan D Acked-by: Tejun Heo Acked-by: Johannes Weiner Acked-by: Dave Hansen --- This patch has been acked and can be routed

Re: [PATCH V6] x86/mm: Tracking linear mapping split events

Hi all, So far I have received two acks for V6 version of my patch > Acked-by: Tejun Heo > Acked-by: Johannes Weiner Are there any more objections ? Thanks, Saravanan D

Re: [PATCH V5] x86/mm: Tracking linear mapping split events

s 789 direct_map_level3_splits 12 <<< Thanks, Saravanan D

Re: [PATCH V5] x86/mm: Tracking linear mapping split events

plits 784 direct_map_level3_splits 12 bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @ [pid, comm] = count(); }' cat /proc/vmstat | grep -i direct_map_level direct_map_level2_splits 789 direct_map_level3_splits 12 Thanks, Saravanan D

[PATCH V4] x86/mm: Tracking linear mapping split events

mapped to huge pages to smaller ones thereby increasing the probability of TLB miss/reload even after tracing has been stopped. Documentation regarding linear mapping split events added to admin-guide as requested in V3 of the patch. Signed-off-by: Saravanan D --- .../admin-guide/mm

Re: [PATCH V3] x86/mm: Tracking linear mapping split events

being usable on other architectures. Naming them after page table levels makes lot of sense. 2 new vmstat event counters that is relevant for all without the need for #ifdef page size craziness. - Saravanan D

Re: [PATCH V3] x86/mm: Tracking linear mapping split events

Hi Randy, > Documenation/ update, please. I will include it in the V4 patch. - Saravanan D

[PATCH V3] x86/mm: Tracking linear mapping split events

to huge pages to smaller ones thereby increasing the probability of TLB miss/reload even after tracing has been stopped. Signed-off-by: Saravanan D --- arch/x86/mm/pat/set_memory.c | 18 ++ include/linux/vm_event_item.h | 8 mm/vmstat.c | 8 3

Re: [PATCH V2] x86/mm: Tracking linear mapping split events

Hi Tejun, > Saravanan, can you please drop the debugfs portion and repost? Sure. Saravanan D

[PATCH V2] x86/mm: Tracking linear mapping split events

page attribute/permission changes would force the kernel to split code segments mapped to huge pages to smaller ones thereby increasing the probability of TLB miss/reload even after tracing has been stopped. Signed-off-by: Saravanan D --- arch/x86/mm/pat/set_memory.c | 117