From owner-svn-src-head@FreeBSD.ORG Sat May 16 02:31:45 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65CA95BA; Sat, 16 May 2015 02:31:45 +0000 (UTC) Received: from st11p00im-asmtp001.me.com (st11p00im-asmtp001.me.com [17.172.80.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F8B11645; Sat, 16 May 2015 02:31:45 +0000 (UTC) Received: from akita.localnet (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NOF00KFQ5KPX430@st11p00im-asmtp001.me.com>; Sat, 16 May 2015 01:31:38 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-05-15_05:2015-05-15,2015-05-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1505160019 From: Rui Paulo To: Konstantin Belousov Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r282948 - head/lib/libthr/thread Date: Fri, 15 May 2015 18:31:36 -0700 Message-id: <2876732.7TSEeLUW1T@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-reply-to: <201505150840.t4F8eHhM000804@svn.freebsd.org> References: <201505150840.t4F8eHhM000804@svn.freebsd.org> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 02:31:45 -0000 On Friday 15 May 2015 08:40:17 Konstantin Belousov wrote: > Author: kib > Date: Fri May 15 08:40:17 2015 > New Revision: 282948 > URL: https://svnweb.freebsd.org/changeset/base/282948 > > Log: > Some third-party malloc(3) implementations use pthread_setspecific(3) > to handle per-thread information. Since our pthread_setspecific() > implementation calls calloc(3) to allocate per-thread specific data > storage, things get complicated. > > Switch the allocator to use bare mmap(2). There is some loss of the > allocated page, since e.g. on amd64, PTHREAD_KEYS_MAX * sizeof(struct > pthread_specific_elem) is 3K (it actually spans whole page due to > padding), but I believe it is more acceptable than additional code for > specialized allocator(). > > The alternatives would either to make the specific data array be part of > the struct thread, or use internal bindings to call the libc malloc, > avoiding interposing. > > Also do the style pass over the thr_spec.c, esp. simplify the > conditionals nesting by returning early when an error detected. > Remove trivial comments. > > Found by: yuri@rawbw.com > PR: 200138 > Sponsored by: The FreeBSD Foundation > MFC after: 2 weeks Thanks! I think umem might be affected as well. -- Rui Paulo