From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-93277-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 2472 invoked by alias); 15 Jun 2018 05:07:09 -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 2457 invoked by uid 89); 15 Jun 2018 05:07:08 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=compensate
X-HELO: mx1.redhat.com
Subject: Re: Restartable Sequences system call merged into Linux
To: Pavel Machek <pavel@ucw.cz>,
 Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: carlos <carlos@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
 Boqun Feng <boqun.feng@gmail.com>, Thomas Gleixner <tglx@linutronix.de>,
 linux-kernel <linux-kernel@vger.kernel.org>,
 libc-alpha <libc-alpha@sourceware.org>
References: <1084280721.10859.1528746558696.JavaMail.zimbra@efficios.com>
 <31fc101a-295b-067b-1a82-7e9e509fc92f@redhat.com>
 <305409897.10888.1528747473727.JavaMail.zimbra@efficios.com>
 <091061df-3482-8762-30e4-feaf3417be11@redhat.com>
 <417742741.11550.1528821084084.JavaMail.zimbra@efficios.com>
 <20180614122759.GB8798@amd>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <608bdd59-9ddb-bf68-0127-a0c54002b582@redhat.com>
Date: Fri, 15 Jun 2018 05:07:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <20180614122759.GB8798@amd>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-06/txt/msg00431.txt.bz2

On 06/14/2018 02:27 PM, Pavel Machek wrote:

>>> Should we treat it the same way?  Always allocate it for each new thread
>>> and register it with the kernel?
>>
>> That would be an efficient way to do it, indeed. There is very little
>> performance overhead to have rseq registered for all threads, whether or
>> not they intend to run rseq critical sections.
> 
> People with slow / low memory machines would prefer not to see
> overhead they don't need...

I can try to get rid of the >500 byte per-thread area for the stub 
resolver.  That should compensate for the overhead introduced.

Thanks,
Florian