All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: "eugene.loh--- via DTrace-devel" <dtrace-devel@oss.oracle.com>
Cc: dtrace@lists.linux.dev, eugene.loh@oracle.com
Subject: Re: [DTrace-devel] [PATCH] test: Increase syscall entry timeout
Date: Tue, 27 Jan 2026 12:56:43 +0000	[thread overview]
Message-ID: <87cy2v2oz8.fsf@esperi.org.uk> (raw)
In-Reply-To: <20260122220154.20552-1-eugene.loh@oracle.com> (eugene loh's message of "Thu, 22 Jan 2026 17:01:54 -0500")

On 22 Jan 2026, eugene loh outgrape:

> From: Eugene Loh <eugene.loh@oracle.com>
>
> The run time for this test seems twice as long for aarch64 as for
> x86_64.  Further, the run time seems to have jumped significantly from
> kernel 5.15 to 6.12 and then again to kernel 6.18.  E.g.,

Ew.

>                   x86_64     aarch64
>     5.15          7 secs     18 secs
>     6.12         12 secs     33 secs
>     6.18         22 secs     54 secs
>
> Looking at a run on the 6.18 aarch64 system, the time is basically
> spent in the dtrace_close() call to dt_probe_detach_all(), which does:
>
>     for (prp = ...)
>         prp->prov->impl->detach(dtp, prp);
>
> Then, dt_tp_probe_detach() calls dt_tp_detach(), which does:
>
>     close(tpp->fd);
>
> This close() averages over 0.1 secs.  For hundreds of syscall probes,
> we get nearly a minute of run time, exceeding the default test timeout.

Sounds like another O(n^2) crept back in somewhere in the kernel :(

> For the time being, increase the timeout on this test.
>
> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>

Reviewed-by: Nick Alcock <nick.alcock@oracle.com>

      reply	other threads:[~2026-01-27 12:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 22:01 [PATCH] test: Increase syscall entry timeout eugene.loh
2026-01-27 12:56 ` Nick Alcock [this message]

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=87cy2v2oz8.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.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.