High CPU usage associated to busy loop in curl_timediff_us()

From: Stephane Cruchon via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 12 Sep 2025 07:30:36 +0000

Hi Daniel,

Many thanks for your feedback !
I have more considering to the context when it happen.

Last occurrence showed 8 threads stuck without any IO and occupying 100 % CPU.
Each thread is handling hundreds of connections / messages towards http AS.

I checked the history of Curl_splay function - last modification was :

------------------------------------------------------------------------------------
$ git log -L :Curl_splay:lib/splay.c
commit dcb51bafabf9d0776135de9111c1a3fe437d570c
Author: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu Aug 15 16:13:23 2024 +0200

    splay: use access functions, add asserts, use Curl_timediff
    - add set/get functions for the custom data in a tree node
    - use Curl_timediff for time comparisons instead of the custom macro, as they
      do the exact same things.
    - add asserts to catch mistakes better
    - updated test 1309 accordingly

    Closes #14562
------------------------------------------------------------------------------------

Is it this modification that could help us maybe ?

Regards,


-----Message d'origine-----
De : Daniel Stenberg <daniel_at_haxx.se>
Envoyé : mercredi 10 septembre 2025 23:20
À : Stephane Cruchon via curl-library <curl-library_at_lists.haxx.se>
Cc : Stephane Cruchon <stephane.cruchon_at_actility.com>; Gilles Lefèvre <gilles.lefevre_at_actility.com>; R&D Support <supportrd_at_actility.com>
Objet : Re: High CPU usage associated to busy loop in curl_timediff_us()

[You don't often get email from daniel_at_haxx.se. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Wed, 10 Sep 2025, Stephane Cruchon via curl-library wrote:

> We've observed a situation where curl_timediff_us() seems to spin in a
> tight loop when libcurl runs inside a container. This leads to high cpu usage.

What happened that took libcurl to this state? What is curl doing when this happens?

curl_timediff_us() itself does not get stuck and in the follow up email you indicated that it might be related to the splay tree management.

We fixed a splay related issue recently, so maybe the latest version works better for you.

I doubt it is actually related to the time.

--
  / daniel.haxx.se || https://rock-solid.curl.dev
[Logo]<https://www.actility.com/>       [Logo]
Stephane Cruchon
R&D team Manager Support
Buy hardware in ThingPark Market<https://market.thingpark.com/>, try (free) on ThingPark Community<https://community.thingpark.org/>, deploy with Actility<https://www.actility.com/>
[Banner]<https://www.actility.com/timeline-of-events/>
The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. Actility.
-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2025-09-12