On Fri, Feb 18, 2022 at 3:20 PM HAGIO KAZUHITO(萩尾 一仁) <[email protected]> wrote:
> 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? > There seems to be 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? > No, I didn't see it, and only saw it in internal bugs. It would be better to add it to a commit log or/and code comment. > That would be good if anyone knows about the related discussion. Thanks. Lianbo > Thanks, > Kazu > >
-- Crash-utility mailing list [email protected] https://listman.redhat.com/mailman/listinfo/crash-utility
