Hi David, On Tue, Feb 21, 2023 at 4:14 AM David Wysochanski <dwysocha@xxxxxxxxxx> wrote: > > On Tue, Feb 7, 2023 at 11:34 PM Tao Liu <ltao@xxxxxxxxxx> wrote: > > > > Hello, > > > > Recently I made an attempt to introduce a thread pool for crash utility, to > > optimize the performance of crash. > > > > One obvious point which can benefit from multi-threading is memory.c:vm_init(). > > There are hundreds of MEMBER_OFFSET_INIT() related symbol resolving functions, > > and most of the symbols are independent from each other, by careful arrangement, > > they can be invoked parallelly. By doing so, we can shorten the waiting time of > > crash starting. > > > I realize this isn't the area of the code you mention, but did you consider > using the thread pool to speed up really slow commands such as 'search'? > Great suggestion! It is an interesting topic, I think I can take a try on it. > A while back I was taking some actual data in our production vmcore system > for 'slow' commands (I mean commands that engineers would have running > for hours/days and/or even fire up multiple crash instances to run them). I > cannot recall all of the commands but 'search' was definitely on the top of > the list. Could you please provide a vmcore which takes crash hours/days for analysis, or steps I can reproduce it? Then I can debug and have a comparison of how much the performance can be improved by multi-threading. Thanks, Tao Liu > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/crash-utility > Contribution Guidelines: https://github.com/crash-utility/crash/wiki > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
