Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: CPU usage since 8.7.1
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 30 Oct 2025 15:35:25 +0100
> Am 30.10.2025 um 15:22 schrieb Cristian Rodríguez <cristian_at_rodriguez.im>:
>
> On Thu, Oct 30, 2025 at 10:47 AM Stefan Eissing <stefan_at_eissing.org> wrote:
>>
>>
>>
>>> Am 30.10.2025 um 14:46 schrieb Stefan Eissing <stefan_at_eissing.org>:
>>>
>>>
>>>
>>>> Am 30.10.2025 um 14:38 schrieb Cristian Rodríguez <cristian_at_rodriguez.im>:
>>>>
>>>> On Wed, Oct 29, 2025 at 10:47 PM Gleb Smirnoff via curl-library
>>>> <curl-library_at_lists.haxx.se> wrote:
>>>>
>>>>> --- a/lib/transfer.c
>>>>> +++ b/lib/transfer.c
>>>>> _at__at_ -280,9 +280,10 _at__at_ static CURLcode sendrecv_dl(struct Curl_easy *data,
>>>>>
>>>>> if(bytestoread && data->set.max_recv_speed > 0) {
>>>>> /* In case of speed limit on receiving: if this loop already got
>>>>> - * data, break out. If not, limit the amount of bytes to receive.
>>>>> - * The overall, timed, speed limiting is done in multi.c */
>>>>> - if(total_received)
>>>>> + * a quarter of the quota, break out. We want to stutter a bit
>>>>> + * to keep in the limit, but too small receives will just cost
>>>>> + * cpu unnecessarily. */
>>>>> + if(total_received >= (data->set.max_recv_speed / 4))
>>>>> break;
>>>>> if(data->set.max_recv_speed < (curl_off_t)bytestoread)
>>>>> bytestoread = (size_t)data->set.max_recv_speed;
>>>>>
>>>>> Thanks!
>>>>
>>>>
>>>> This is on an special BSD system or what? because on Linux this is the
>>>> wrong way of doing it.. the kernel can ratelimit your transfers way
>>>> more efficiently using SO_MAX_PACING_RATE
>>>
>>> That is for outgoing packets, right=
>>
>> should have been with a question mark...
>
> Yes, incoming will be better served by running the current program in
> a different network namespace with the tc rules or some fancy
> container runtime that enforces your limits at a different lower
> level.
That would allow individual connections with different, possibly dynamic RX pacing for the same application? I believe you are talking about a more narrow use case than what is the scope here.
- Stefan
Date: Thu, 30 Oct 2025 15:35:25 +0100
> Am 30.10.2025 um 15:22 schrieb Cristian Rodríguez <cristian_at_rodriguez.im>:
>
> On Thu, Oct 30, 2025 at 10:47 AM Stefan Eissing <stefan_at_eissing.org> wrote:
>>
>>
>>
>>> Am 30.10.2025 um 14:46 schrieb Stefan Eissing <stefan_at_eissing.org>:
>>>
>>>
>>>
>>>> Am 30.10.2025 um 14:38 schrieb Cristian Rodríguez <cristian_at_rodriguez.im>:
>>>>
>>>> On Wed, Oct 29, 2025 at 10:47 PM Gleb Smirnoff via curl-library
>>>> <curl-library_at_lists.haxx.se> wrote:
>>>>
>>>>> --- a/lib/transfer.c
>>>>> +++ b/lib/transfer.c
>>>>> _at__at_ -280,9 +280,10 _at__at_ static CURLcode sendrecv_dl(struct Curl_easy *data,
>>>>>
>>>>> if(bytestoread && data->set.max_recv_speed > 0) {
>>>>> /* In case of speed limit on receiving: if this loop already got
>>>>> - * data, break out. If not, limit the amount of bytes to receive.
>>>>> - * The overall, timed, speed limiting is done in multi.c */
>>>>> - if(total_received)
>>>>> + * a quarter of the quota, break out. We want to stutter a bit
>>>>> + * to keep in the limit, but too small receives will just cost
>>>>> + * cpu unnecessarily. */
>>>>> + if(total_received >= (data->set.max_recv_speed / 4))
>>>>> break;
>>>>> if(data->set.max_recv_speed < (curl_off_t)bytestoread)
>>>>> bytestoread = (size_t)data->set.max_recv_speed;
>>>>>
>>>>> Thanks!
>>>>
>>>>
>>>> This is on an special BSD system or what? because on Linux this is the
>>>> wrong way of doing it.. the kernel can ratelimit your transfers way
>>>> more efficiently using SO_MAX_PACING_RATE
>>>
>>> That is for outgoing packets, right=
>>
>> should have been with a question mark...
>
> Yes, incoming will be better served by running the current program in
> a different network namespace with the tc rules or some fancy
> container runtime that enforces your limits at a different lower
> level.
That would allow individual connections with different, possibly dynamic RX pacing for the same application? I believe you are talking about a more narrow use case than what is the scope here.
- Stefan
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-10-30