[LTP] [PATCH] ksm: fix segfault on s390

Jan Stancek jstancek@redhat.com
Fri May 23 08:13:50 CEST 2025


On Thu, May 22, 2025 at 4:36 PM Li Wang via ltp <ltp@lists.linux.it> wrote:
>
> Luiz Capitulino <luizcap@redhat.com> wrote:
>
> > > I might be a bit too picky:). So I compared the two approaches on a
> > > 2 CPUs, KVM, x86_64 system:
> > >
> > > Per-block checking cost time:
> > >     real 0m5.862s
> > >     user 0m1.098s
> > >     sys 0m1.505s
> > >
> > > Per-byte checking cost time:
> > >    real    0m6.819s
> > >    user    0m2.498s
> > >    sys     0m1.495s
> > >
> > >  From the data, block-by-block checking can reduce the total execution
> > > time by about 14% and reduce CPU usage by more than 35%, especially
> > > in user-space calculations. This number may not be large, but considering
> > > that tests are frequently run in CI, I think it would be a good thing if we can
> > > reduce 1 second each time :).
> >
> > Just to make sure I understand: you measured total test run-time, correct?
> > How many times did you run it?
> >
> > In any case, I'm not sure a 1 second run-time (or even CPU utilization) matters
> > that much. You're running test code, you shouldn't expect otherwise unless you
> > hit a very bad case (say something taking several hours to complete).
> >
> > The trade off is more complex code with bugs that can hide for 10+ years and
> > take developer time to debug. Also, higher memory utilization: 's' doubles
> > memory utilization per child only to do that check.
>
> Ture, that's why the problem not been find so many years!
>
> >
> > So, I suggest we stick to the simpler code. Or, get it merged now (since it's
> > fixing a bug and possibly making the code _faster_) and then you can optimize
> > on top later if you like.
>
> Ok, sounds reasonable.
>
> Reviewed-by: Li Wang <liwang@redhat.com>
>
> @Cyril, @Petr, I vote to merge this one (as it is) before our May release.

Acked-by: Jan Stancek <jstancek@redhat.com>

>
> --
> Regards,
> Li Wang
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>



More information about the ltp mailing list