From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-73811-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 43432 invoked by alias); 7 Oct 2016 18:20:04 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 43422 invoked by uid 89); 7 Oct 2016 18:20:03 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=burden
X-HELO: mail-ua0-f171.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:subject:to:references:cc:from:message-id:date
         :user-agent:mime-version:in-reply-to:content-transfer-encoding;
        bh=8pVZjn5KXGuMCzdBhDDOEIB8xBGhWzOfhD5DHKM2r0w=;
        b=iCz8HHf5X0522wsGUAeH0kNtI4buu7Ic/F7Sv3unNE3PL7CR4hvSLq78CajdqnGjhT
         RqygXkkbo3/UcvFupTl+PHbcNld1bPQq7unhDBSVPnWL0KMiBLICoVm1Ni3dCDLv8TdF
         Q9uaO6063CLpVa5R/pYXtUZ5NKAMhPO+zJoKj2ul+OwH+CQTdyKEHXMj2a08MFBb2YDP
         XGI0nK1sj8h3m4d6ocB+u4izsOMPnnW8NWKmqGSDWy9D9SBzWBkcCh8O3S2EaTHBFkhk
         F7RYWVgUf8vjeT9RWl8kXSmc8QRnAFMR/7VdYmQXn60LwIP2ImkK1juvnGbKIDHAMDV2
         Bq1w==
X-Gm-Message-State: AA6/9RnEv1epYz9NEgBu+w9zdsO4S+3Ar0MrReeabTF9KhDeFi4FQ/vgodRUdmNu1PAQXPQe
X-Received: by 10.159.39.229 with SMTP id b92mr15754803uab.158.1475864391430;
        Fri, 07 Oct 2016 11:19:51 -0700 (PDT)
Subject: Re: Caching of PID/TID after fork
To: =?UTF-8?Q?Robert_=c5=9awi=c4=99cki?= <robert@swiecki.net>,
 Zack Weinberg <zackw@panix.com>
References: <CAP145pj+yVz_7ZF8_dNqZ2NE22A_O5QyT195Gy0TgvKq1j3skw@mail.gmail.com>
 <20161006172631.GO19318@brightrain.aerifal.cx>
 <CAP145pjLiwhx4P3XJQCBrpg=OBmaHWyHHOkvT82eSJ4s8aFLZQ@mail.gmail.com>
 <20161006180514.GP19318@brightrain.aerifal.cx>
 <CAP145phG3DL2nFmA32Lu2J_aQEahKT1CoZrNJaGDn76Mov32Ww@mail.gmail.com>
 <CAP145pgU=Ph1UHntkZoEFwneEGCVzzb8YhyzjJBt69wxPemRkg@mail.gmail.com>
 <CAKCAbMhZ4ddn3RrqkKg2fr_x_pK6X7DwmPVfb3ZLvcZJqGVJJA@mail.gmail.com>
 <CAKCAbMg+FzVQmSu2+yOZXngxb9z9hp6vHfKZJv_vwVs3UJMs_Q@mail.gmail.com>
 <CAP145piogrms_OXBSrNsrVM8RH6d0sVv4A5UgyF-BGqz1RdBHQ@mail.gmail.com>
Cc: GLIBC Devel <libc-alpha@sourceware.org>
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Message-ID: <175e5485-faef-80f9-5a4d-9aa7c4c8f2c4@linaro.org>
Date: Fri, 07 Oct 2016 18:20:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <CAP145piogrms_OXBSrNsrVM8RH6d0sVv4A5UgyF-BGqz1RdBHQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-SW-Source: 2016-10/txt/msg00171.txt.bz2



On 07/10/2016 11:44, Robert Święcki wrote:
> 2016-10-07 2:43 GMT+02:00 Zack Weinberg <zackw@panix.com>:
> 
>>> I've thought for quite some time that there should be a second
>>> clone-wrapper in glibc that doesn't ask for a new stack.  It might be
>>> better to call it something with "clone" in the name, but I don't care
>>> terribly much.
>>
>> Meant to say: in addition to the PID/TID caching issues, this would be
>> able to run pthread_atfork() handlers.
> 
> Maybe..
> 
>  __clone3(unsigned long clone_flags, void* newsp, pid_t*
> parent_tidptr, pid_t* child_tidptr, void* tls);
> 
> ?
> 
> __clone2 seems to be used with ia64 already.
> 

The problem about this approach for clone it is current platform
specific, meaning it requires an assembly crafted routine for each
port.  Adding another one will require additional burden of making
current clone implementation either generic to provide clone and
clone3 or adding another clone3 implementation for *each* port.
And it would also add more additional effort for new ports.

I still think a better approach would be to just focus on try
remove the caching altogether without introducing performance
regressions.