7:10 p.m.
-----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.
Maybe it was better to write the status on the commit log..
[1] https://listman.redhat.com/archives/crash-utility/2021-December/msg00062....
Thanks,
Kazu
9:37 p.m.
New subject: [PATCH v2] Handle blk_mq_ctx member changes for kernels v5.16-rc1~75^2~44
Hi, Steffen and Kazu
Sorry, I missed this information.
On Tue, Jan 4, 2022 at 9:10 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
-----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.
BTW: Also added IIya to cc list.
Thanks.
Lianbo
Maybe it was better to write the status on the commit log..
1:20 a.m.
New subject: [PATCH v2] Handle blk_mq_ctx member changes for kernels v5.16-rc1~75^2~44
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
2:53 a.m.
New subject: [PATCH v2] Handle blk_mq_ctx member changes for kernels v5.16-rc1~75^2~44
On Fri, Feb 18, 2022 at 3:20 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com wrote:
That would be good if anyone knows about the related discussion.
Thanks.
Lianbo
> Thanks,
> Kazu
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.
1009
days inactive
1057
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
HAGIO KAZUHITO(萩尾 一仁) -
lijiang