All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Li Wang <liwang@redhat.com>
Cc: ltp@lists.linux.it, Luiz Capitulino <luizcap@redhat.com>
Subject: Re: [LTP] [PATCH] ksm: fix segfault on s390
Date: Thu, 22 May 2025 21:52:15 +0200	[thread overview]
Message-ID: <20250522195215.GA30761@pevik> (raw)
In-Reply-To: <CAEemH2dx1HFd1jxjtujA3JHAQBER4RrW_xiW0tS5xb5M2pkhiw@mail.gmail.com>

Hi Li, Luiz,

> 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.

LGTM.
Reviewed-by: Petr Vorel <pvorel@suse.cz>

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-05-22 19:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20 20:24 [LTP] [PATCH] ksm: fix segfault on s390 Luiz Capitulino via ltp
2025-05-21 14:08 ` Li Wang via ltp
2025-05-21 17:10   ` Luiz Capitulino via ltp
2025-05-21 23:27     ` Li Wang via ltp
2025-05-22  5:29       ` Li Wang via ltp
2025-05-22 14:08         ` Luiz Capitulino via ltp
2025-05-22 14:36           ` Li Wang via ltp
2025-05-22 19:52             ` Petr Vorel [this message]
2025-05-23  6:13             ` Jan Stancek via ltp
2025-05-22 14:49           ` Li Wang via ltp
2025-05-27  9:40 ` Cyril Hrubis
2025-05-27  9:50   ` Li Wang via ltp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250522195215.GA30761@pevik \
    --to=pvorel@suse.cz \
    --cc=liwang@redhat.com \
    --cc=ltp@lists.linux.it \
    --cc=luizcap@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.