On Fri, Apr 6, 2018 at 9:10 AM Dave Anderson <anderson@xxxxxxxxxx> 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. -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
