Hi

On 03/12/2018 11:53, Cristian Marussi wrote:
> Hi
> 
[snip]
> same for me. Issue still there.
> 
> Beside I saw some differences in the dbench result which I used for testing.
> 
> From the dbench (comparing with previous mail) it seems that
> Unlink and Qpathinfo MaxLat has normalized.
> 
>  Operation      Count    AvgLat    MaxLat
>  ----------------------------------------
>  NTCreateX      90820    13.613 13855.620
>  Close          66565    18.075 13853.289
>  Rename          3845    23.668   326.642
>  Unlink         18450     4.581   186.062
>  Qpathinfo      82068     2.677   280.203
>  Qfileinfo      14235    10.357   176.373
>  Qfsinfo        15156     2.822   242.794
>  Sfileinfo       7400    17.018   240.546
>  Find           31812     5.988   277.332
>  WriteX         44735     0.155    14.685
>  ReadX         141872     0.741 13817.870
>  LockX            288    10.558    96.179
>  UnlockX          288     3.307    57.939
>  Flush           6389    20.427   187.429
> 
> 
>> Is there anything else blocked in the RPC layer? The above are all
>> standard tasks waiting for the rpciod/xprtiod workqueues to complete
>> the calls to the server.
> cat  /proc/692/stack
> [<0>] __switch_to+0x6c/0x90
> [<0>] rescuer_thread+0x2e8/0x360
> [<0>] kthread+0x134/0x138
> [<0>] ret_from_fork+0x10/0x1c
> [<0>] 0xffffffffffffffff
> 
> I was now trying to collect more evidence ftracing during the quiet-stuck-period
> till the restart happens.
> 

attached to this mail there is a 3secs ftrace function-graph taken during the
quiet/stalled period of an 'LKP run dbench'; issued directly from console (no
ssh or netcat shell traffic).

Ftrace filter was pre-set as:

set_ftrace_filter was set to : nfs* rpc* xprt* tcp*

and tracing started once NO traffic was observed flowing on Wireshark.

Using ARM64 64k pages on Linux NFS next branch like previous mail this morning.

Thanks

Cristian