On Wed, Feb 22, 2023 at 1:57 AM Tao Liu <ltao(a)redhat.com> wrote:
Hi David,
On Tue, Feb 21, 2023 at 4:14 AM David Wysochanski <dwysocha(a)redhat.com> wrote:
>
> On Tue, Feb 7, 2023 at 11:34 PM Tao Liu <ltao(a)redhat.com> 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.
Fantastic, thanks Tao!
> 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.
Yes I'm sure either myself or someone else can provide at least one.
I'll do a little bit of digging then follow up with an email to you off-list
about it.