Re: Guideline change: glibc malloc as the C/C++/Rust allocator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 26.7.2018 v 20:58 Carlos O'Donell napsal(a):
> On 07/26/2018 12:24 PM, Vít Ondruch wrote:
>>
>> Dne 26.7.2018 v 18:03 Jason L Tibbitts III napsal(a):
>>>>>>>> "FW" == Florian Weimer <fweimer@xxxxxxxxxx> writes:
>>> FW> I would like to request a change of the Packaging Guidelines,
>>> FW> advising packagers not to interpose malloc.
>>>
>>> How strong of a restriction are you looking for?  This sort of feels
>>> like something which would at the strongest be a "SHOULD NOT" but maybe
>>> you're looking for an absolute ban.
>>>
>>> Some maintainers may find it difficult to comply with an absolute ban if
>>> the relevant software doesn't make it easy to change the allocator.  And
>>> some upstreams may have strong preferences for one allocator over
>>> another (which I imagine would often be linked to performance).  Will
>>> assistance be offered to modify affected packages?  What about
>>> contacting upstreams?
>>>
>>> How many packages would need to change to meet this guideline?
>> Just FTR, there is ongoing discussion about changing default to jemalloc
>> in Ruby:
>>
>> https://bugs.ruby-lang.org/issues/14718
>>
>> Wouldn't it be better if glibc maintainers joined such discussions to
>> improve glibc malloc implementation?
> This is an orthogonal problem. I've responded in the Ruby ticket.

I very appreciate your response to upstream ticket, because otherwise,
you know, I am the one who would have to justify whatever the decision
would be to one or to the other side. But I don't really want to take
sides ....

> Improving glibc's malloc will take time, and we have already started.
>
> We tackled performance for qemu and DJ Delorie implemented lockless thread
> caching to reduce the fast path just like tcmalloc and jemalloc.
>
> The next step is to tackle RSS and it is poorly understand and non-trivial.

I understand. Thx for the effort.

V.

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/RDUVGACOYBVARJWB6TXOU3DFDRK3J363/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux