This is the mail archive of the
mailing list for the glibc project.
Re: [PATCHv2 0/2] Tunables for glibc
- From: "Tulio Magno Quites Machado Filho" <tuliom at linux dot vnet dot ibm dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>, Andrew Pinski <pinskia at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, munroesj at linux dot vnet dot ibm dot com
- Date: Thu, 12 May 2016 11:35:42 -0300
- Subject: Re: [PATCHv2 0/2] Tunables for glibc
- Authentication-results: sourceware.org; auth=none
- References: <20160116185503 dot GA17754 at devel dot intra dot reserved-bit dot com> <CA+=Sn1k63+=qNriuR5J5POX4KQBocqsYePZNXzrpf9aSQY4g3w at mail dot gmail dot com> <20160512052321 dot GB5607 at devel dot intra dot reserved-bit dot com>
Siddhesh Poyarekar <firstname.lastname@example.org> writes:
> On Wed, May 11, 2016 at 07:21:18PM -0700, Andrew Pinski wrote:
>> What is status about this feature? I have a case where I want to have
>> a tunable parameter for pthread_mutex_lock where we spin a little bit
>> in userspace before calling futex as people use pthread_mutex's as
>> normal locks and in the case of huge number of cores we should not
>> call futex if the time spent inside the lock is small.
> Florian reviewed the last iteration of the patch and asked me to go
> for a more declarative approach where we make the framework aware of
> the data type of the tunable. I'm doing this on my own time and I
> haven't had a lot of it lately, due to which iterations of the
> patchset are not coming in as regularly as they should. I have a day
> free this weekend and I hope to get a new iteration up in that time.
> However if you need this feature more urgently and have a person who
> can work on it then let me know and I'll help ramp him/her up and help
> with reviews instead.
What about creating a top-tier branch  for tunables with the same policy
That way, whoever has time or new ideas can propose new patches, get community
consensus under the assumption that's targeting specifically the tunables
branch and push them.
In the future, when we finally get a consensus on the whole framework, we can
merge tunables into master.
Right now, the only branch available is siddhesh/tunables which you're the
only committer. Whoever has a new idea needs to update their patches whenever
you update your branch.
I volunteer myself to follow the rest of the process described in the wiki 
and merge master into tunables during the life-time of this branch.