Re: [PATCH v2 3/6] rtla/utils: Add idle state disabling via libcpupower

2024-08-01 Thread Tomas Glozar
> > Need to check if the calloc failed and return an error if it did. > Definitely, I completely missed that. > > Hmm, should this warn if state is not zero and disabled is negative. > rtla timerlat hist/top will error out if save_cpu_idle_disable_state returns a negative value, so I don't think

Re: [PATCH v2 4/6] rtla/timerlat: Add --deepest-idle-state for top

2024-08-01 Thread Tomas Glozar
> > Could probably do: > > #ifdef HAVE_LIBCPUPOWER_SUPPORT > > + "--deepest-idle-state n: only go down to idle > > state n on cpus used by timerlat to reduce exit from idle latency", > #else > + "--deepest-idle-state n: [rtla built without > libcp

Re: [PATCH] rtla: Sync the help text between hist tools

2024-08-13 Thread Tomas Glozar
params->duration = parse_seconds_duration(optarg); if (!params->duration) timerlat_top_usage("Invalid -D duration\n"); break; and the "Invalid -D duration" (instead of "-d") one is also in osnoise_top.c. Those would probably go to a separate patch, though. Reviewed-by: Tomas Glozar Tomas

Re: [PATCH] tracing/timerlat: Check tlat_var for NULL in timerlat_fd_release

2024-08-22 Thread Tomas Glozar
st 21. 8. 2024 v 22:02 odesílatel Steven Rostedt napsal: > > I'm able to reproduce this with the above. Unfortunately, I can still > reproduce it after applying this patch :-( > Thank you for looking at this. I was at first not too sure about whether this is the proper fix, but after some discuss

Re: [PATCH] tracing/timerlat: Check tlat_var for NULL in timerlat_fd_release

2024-08-26 Thread Tomas Glozar
pá 23. 8. 2024 v 20:51 odesílatel Steven Rostedt napsal: > > Egad, I don't think this is even good enough. I noticed this in the trace > (adding kthread to the memset trace_printk): > ><...>-916 [003] . 134.227044: osnoise_workload_start: > memset 88823c435b28 for 00

Re: [PATCH] tracing/timerlat: Check tlat_var for NULL in timerlat_fd_release

2024-08-27 Thread Tomas Glozar
po 26. 8. 2024 v 19:27 odesílatel Steven Rostedt napsal: > > Yeah, I think I finally found the real issue. I don't think we need the ref > counting. The problem is the creating and killing of the threads via the > start and stop callbacks. That's not their purpose. The purpose of stop > and start

Re: [PATCH] nd_btt: Make BTT lanes preemptible

2023-09-17 Thread Tomas Glozar
čt 14. 9. 2023 v 22:18 odesílatel Ira Weiny napsal: > Is the bug in 1 of 2 places? > > 1) When btt_write_pg()->lock_map() (when the number of lanes is < number >of cpus) and the lane is acquired is called? > > *or* > > 2) When nd_region_acquire_lane() internally trys to take it's lock? > > A c

[PATCH v2] nd_btt: Make BTT lanes preemptible

2023-09-19 Thread Tomas Glozar
? __pfx_submit_bio_wait_endio+0x10/0x10 blkdev_write_iter+0x1d8/0x290 vfs_write+0x237/0x330 ... Fixes: 5212e11fde4d ("nd_btt: atomic sector updates") Signed-off-by: Tomas Glozar --- drivers/nvdimm/region_devs.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/nvdimm/regio

Re: [PATCH] nd_btt: Make BTT lanes preemptible

2023-09-19 Thread Tomas Glozar
po 18. 9. 2023 v 23:32 odesílatel Ira Weiny napsal: > Thanks for clarifying. Could you respin the patch with the text below? > That would have saved me a lot of time digging to see what the code path > was. Sent v2 with relevant parts of the BUG message.