From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122365 invoked by alias); 15 May 2017 19:59:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 122134 invoked by uid 89); 15 May 2017 19:59:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=cleanups, distributions, Hx-languages-length:1125, alwayson X-HELO: mx0a-001b2d01.pphosted.com From: "Tulio Magno Quites Machado Filho" To: "Carlos O'Donell" , GNU C Library Cc: Subject: Re: RFC: Always-on elision with per-process opt-in using tunables. In-Reply-To: References: User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.1 (x86_64-unknown-linux-gnu) Date: Mon, 15 May 2017 19:59:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable x-cbid: 17051519-0020-0000-0000-000002A95643 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051519-0021-0000-0000-000030C6C6B5 Message-Id: <87pof9yjqm.fsf@totoro.br.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-15_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705150188 X-SW-Source: 2017-05/txt/msg00459.txt.bz2 Carlos O'Donell writes: > I am going to propose the following: > > * Always build with elision support. > > * Elision disabled by default at runtime. > > * Use tunables to allow processes to opt-in to transparent elision. > > The benefit is that the elision support doesn't bit-rot, and we keep > it working, and that distributions can conservatively backport elision > and allow users to test enablement on a per-process basis. > > The elision is enabled with: > > GLIBC_TUNABLE=glibc.elision.enable=1 I like this proposal. > The obvious set of patches are: > > (a) Split out some cleanups in this patch. > (b) Always build with elision and us tunables to opt-in. > (c) Extend tunables to allow modification of elision parameters > (useful for upcoming rwlock elision re-enablement). Paul Murphy had a patch to implement this step. It could be useful, although it's outdated: https://patchwork.sourceware.org/patch/10342/ Another patch to the set you suggested: (d) Extend the testsuite to test elided locks too. -- Tulio Magno