On Fri, Apr 6, 2018 at 9:10 AM Dave Anderson <anderson(a)redhat.com> wrote:
 ----- Original Message -----
 > This series decreases crash startup and 'ps' processing time when
handling dumps
 > with many tasks.  Prior to the series a 1M task dump took 45m to
load 
and 45m
 > more to run ps.  Once patched, startup+ps time drops below 40
seconds. 
 Hi Greg, 
 This sounds really good, although I have to say I've never
encountered a 
dumpfile
 that had such a large task count.  I will review and test the
patch-set 
next week.
Thanks.
 BTW, did you test this on a live system that has such a large task
count?
 Like for example, as I recall, the task_exists() checks that you removed 
are
 checking for tasks that were found when scanning the lists, but gone
by 
the
 time it got around to storing them. 
I have used these patches on a live machine.  'ps' runs and appears
correct.  Though it's a moving target, so difficult to say if every line is
perfect.  I don't see any duplicates.  And I see a similar set of pids to
what /bin/ps reports.  Though /bin/ps consistently reports a subset (~1000
fewer pids than crash reports).  For these /bin/ps-mising pids, they are
visible in /proc/$pid and "kill -0 $pid" also works.  So I think it's a
either a procfs bug or /bin/ps bug.  stracing /bin/ps doesn't show any
syscall errors.