8:29 p.m.
Hello Dave,
The patch is used to improve the existing command, which adds an
option "-c"
to the the command "runq". The option "-c" displays the timestamp
information about
the runqueue each of cpu. The timstamp information, which accordings to the
kernel
version you use, may be the value of runqueue's member. for example,
rq.clock or
rq.timestamp_last_tick, even runqueue.timestamp_last_tick.
Besides, I have already tested it on rhel4.8/rehl5.7/rhel6.2,
without any error.
The result like this:
crash> runq -c
CPU 0: 66789719522523
CPU 1: 66789719628339
CPU 2: 66789719519625
Regards,
Wei Jiangang
1:56 p.m.
----- Original Message -----
Hello Dave,
The patch is used to improve the existing command, which adds an option "-c"
to the the command "runq". The option "-c" displays the timestamp
information about
the runqueue each of cpu. The timstamp information, which accordings to the kernel
version you use, may be the value of runqueue's member. for example, rq.clock or
rq.timestamp_last_tick, even runqueue.timestamp_last_tick.
Besides, I have already tested it on rhel4.8/rehl5.7/rhel6.2, without any error.
The result like this:
> crash> runq -c
> CPU 0: 66789719522523
> CPU 1: 66789719628339
> CPU 2: 66789719519625
Regards,
Wei Jiangang
Wei,
What is the debugging scenario that you feel the need to know the
timestamp of each cpu's runqueue? Perhaps you want to compare it to
the "ps -l" output?
Dave
10:03 p.m.
Hi Dave，
As you mentioned in last email, sometimes, we really need to compare
timestamps of runqueue objects with those of current task's task_struct
objects .
The usecase where such feature is needed is the situation where
curcent
processes in crash dump is in the state with interrupt disabled. Then timer
interrupts is also disabled, so there's clear difference between CPU's
timestamp
and current task's timestamp. The latter can be abtainned easily by using ps
-l.
But the field names of timestamp values in runqueue objects vary according
to
kernel versions, it's inconvenient and troublesome to get needed information
about runqueue's timestamp for users. That's why adding an option to runq
command.
Any question please contact with me.
Regards,
Wei Jiangang
----- Original Message -----
Hello Dave,
The patch is used to improve the existing command, which adds an
option
"-c"
to the the command "runq". The option "-c"
displays the timestamp
information about
the runqueue each of cpu. The timstamp information, which accordings
to
the kernel
version you use, may be the value of runqueue's member. for
example,
rq.clock or
rq.timestamp_last_tick, even runqueue.timestamp_last_tick.
Besides, I have already tested it on rhel4.8/rehl5.7/rhel6.2,
without any error.
The result like this:
> crash> runq -c
> CPU 0: 66789719522523
> CPU 1: 66789719628339
> CPU 2: 66789719519625
Regards,
Wei Jiangang
Wei,
What is the debugging scenario that you feel the need to know the
timestamp of each cpu's runqueue? Perhaps you want to compare it to
the "ps -l" output?
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
9:09 a.m.
----- Original Message -----
Hi Dave，
As you mentioned in last email, sometimes, we really need to compare
timestamps of runqueue objects with those of current task's task_struct
objects .
The usecase where such feature is needed is the situation where curcent
processes in crash dump is in the state with interrupt disabled. Then timer
interrupts is also disabled, so there's clear difference between CPU's timestamp
and current task's timestamp. The latter can be abtainned easily by using ps -l.
But the field names of timestamp values in runqueue objects vary according to
kernel versions, it's inconvenient and troublesome to get needed information
about runqueue's timestamp for users. That's why adding an option to runq
command.
Any question please contact with me.
Right -- so this information is really only helpful if it is in collaboration
with the timestamp of the active task on each cpu.
But it seems counterintuitive to have to "runq -c" to show the timestamps, and
then have to go run "ps -l" to dig out out the active command that is running
on
that cpu, and then compare them.
I'm thinking that it might make more sense to either:
(1) have the "runq -c" (or maybe "-t"?) option show each cpu's
runqueue timestamp
followed by the timestamp of the active task on that cpu, or
(2) have the "ps -l" (or maybe a new "ps -L"?) option that first
displays the
per-cpu timestamps, followed by the sorted tasks' timstamps
I think I prefer (1). What do you think?
Dave
Regards,
Wei Jiangang
----- Original Message -----
> Hello Dave,
> The patch is used to improve the existing command, which adds an
option "-c"
> to the the command "runq". The option "-c" displays the
timestamp
information about
> the runqueue each of cpu. The timstamp information, which
> accordings to
the kernel
> version you use, may be the value of runqueue's member. for
> example,
rq.clock or
> rq.timestamp_last_tick, even runqueue.timestamp_last_tick.
> Besides, I have already tested it on rhel4.8/rehl5.7/rhel6.2,
without any error.
> The result like this:
> > crash> runq -c
> > CPU 0: 66789719522523
> > CPU 1: 66789719628339
> > CPU 2: 66789719519625
>
> Regards,
> Wei Jiangang
Wei,
What is the debugging scenario that you feel the need to know the
timestamp of each cpu's runqueue? Perhaps you want to compare it to
the "ps -l" output?
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
4910
days inactive
4911
days old
devel@lists.crash-utility.osci.io
3 comments
2 participants
participants (2)
-
Dave Anderson -
WeiJiangang