This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: malloc: performance improvements and bugfixes
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Joern Engel <joern at purestorage dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, Will Newton <will dot newton at linaro dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, y dot gribov at samsung dot com, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Mike Frysinger <vapier at gentoo dot org>, Paul Eggert <eggert at cs dot ucla dot edu>, Florian Weimer <fweimer at redhat dot com>, Steven Munroe <sjmunroe at us dot ibm dot com>, lopezibanez at gmail dot com
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Joern Engel <joern at purestorage dot org>
- Date: Thu, 28 Jan 2016 08:51:34 -0500
- Subject: Re: malloc: performance improvements and bugfixes
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com>
On 01/25/2016 07:24 PM, Joern Engel wrote:
> From: Joern Engel <joern@purestorage.org>
>
> Short version:
> We have forked libc malloc and added a bunch of patches on top. Some
> patches help performance, some fix bugs, many just change the code to
> my personal liking. Here is a braindump that is _not_ intended to be
> merged, at least not as-is. But individual bits could and should get
> extracted.
You certainly have done quite a bit of work to tune glibc's general
purpose allocator into something that specifically suits your application
needs. Thank you for sharing the high-level details of your changes.
I appreciate your posting of these patches to the mailing list, they are
certainly a very interesting (even if I can't read them beyond their
general description, and I wish I could).
I would like to respond formally, as an GNU project steward for the GNU
C Library project to the top of this thread and make two points very
clear (not buried in another thread):
(1) The GNU C Library project, as a GNU project, requires copyright
assignment for legally significant changes by a particular author.
This requirement is linked to here: "contribution checklist":
http://www.gnu.org/software/libc/development.html
See the "FSF copyright assignment":
https://sourceware.org/glibc/wiki/Contribution%20checklist
If you have any questions, please reach out directly to the FSF.
Even though you never intended to submit these patches for inclusion,
as you say in your email, you stand to taint anyone who reads these
changes and then tries to implement similar work. This is nothing new,
we face this challenge every day, but it bears repeating and you
present the perfect opportunity to reiterate this message.
(2) Objective performance evaluations.
We take microbenchmarking and whole-system benchmarking very seriously
and any changes presented by anyone, senior or junior, should provide
methods of objective evaluation of performance.
While I know you did not intend your posts to be considered for
formal inclusion, it is still a good time to point out the above
two important criteria. This way others watching don't wonder why
we didn't simply include your patches directly into glibc master
with some minor cleanups.
>From patch inception to commit there is always a lot of work to
do for a core project like glibc.
I hope and look forward to your future submissions to the project.
Cheers,
Carlos.