Hi Lianbo, -----Original Message----- > -----Original Message----- > > Admittedly, I haven't looked into the details, but those simple > numbers for > > pending IO have been very valuable for me, when analyzing dumps with > > dm-multipath over (FC-attached) SCSI disks. Aren't those pending IO > numbers > > available elsewhere in the kernel? Maybe not in debugfs anymore, but > I suppose > > the (mq) block layer does keep track of them? > > AFAIK, unfortunately there is no simple counter, crash needs to parse > sbitmap > structures to count them. (please let us know if there is a simpler > solution.) > Currently Sergey has worked on adding sbitmap function [1], and we plan > to make > use of it after merging the patch. It may take some time, so Lianbo's > patch is > a temporary workaround for the error. > > In addition, I would like to add that the counter for the > ctx->rq_completed/ctx->rq_dispatched(for 'dev > -d') may become inaccurate due to racing per-cpu values in the kernel. I'm > considering whether crash should > print a warning or "not supported" for "dev -d", which can avoid misleading > users. So far we have encountered > two similar cases. > > What's your opinion?Kazu.
Thank you for raising this up. The counters can have been inaccurate with multiple CPUs since the introduction of them in kernel, right? No other conditions? Hmm, in this case, personally I would suggest to print a warning on machines with multiple cpus. btw, is there any upstream patch or email saying about the inaccuracy? It would be better to add it to a commit log or/and code comment. Thanks, Kazu -- Crash-utility mailing list [email protected] https://listman.redhat.com/mailman/listinfo/crash-utility
