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 14:47:06 +0100
> 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 @@ 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...
Date: Thu, 30 Oct 2025 14:47:06 +0100
> 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 @@ 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...
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-10-30