On Mon, Sep 02, 2019 at 10:54:41PM +0800, Xiaoguang Wang wrote: > Sometimes process will be stalled in "wait_on_bit_io(&bh->b_state, > BH_Shadow, TASK_UNINTERRUPTIBLE)" for a while, and in order to analyse > app's latency thoroughly, add a new tracepoint to track this delay. > > Trace info likes below: > fsstress-5068 [008] .... 11007.757543: jbd2_sleep_on_shadow: dev 254,17 sleep 1 > fsstress-5070 [007] .... 11007.757544: jbd2_sleep_on_shadow: dev 254,17 sleep 2 > fsstress-5069 [009] .... 11007.757548: jbd2_sleep_on_shadow: dev 254,17 sleep 2 > fsstress-5067 [011] .... 11007.757569: jbd2_sleep_on_shadow: dev 254,17 sleep 1 > fsstress-5063 [007] .... 11007.757651: jbd2_sleep_on_shadow: dev 254,17 sleep 2 > fsstress-5070 [007] .... 11007.757792: jbd2_sleep_on_shadow: dev 254,17 sleep 0 > fsstress-5071 [011] .... 11007.763493: jbd2_sleep_on_shadow: dev 254,17 sleep 1 > > Signed-off-by: Xiaoguang Wang <xiaoguang.wang@xxxxxxxxxxxxxxxxx> I think maybe it might be better to use units of microseconds and then change sleep to usleep so the units are clear? This is a spinlock, so it should be quick. For the other patch in this series, milliseconds seems fine, but if we change the trace info to use "msleep" instead that would be clearer --- or you could change it to use microseconds as well just for consistency; I think either would be fine. What do you think? Cheers, - Ted
