[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEg67G=RUFOPm25KOG8sfqBMR9J5SaA6Jsvc2XNs4QOTXNq-3w@mail.gmail.com>
Date: Tue, 1 May 2018 12:35:58 +1000
From: Patrick Oppenlander <patrick.oppenlander@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Some questions
On Tue, May 1, 2018 at 1:35 AM, Rich Felker <dalias@...c.org> wrote:
> On Mon, Apr 30, 2018 at 01:55:16PM +1000, Patrick Oppenlander wrote:
>> I was talking about the case of a uniprocessor system running a multi
>> theaded process.
>>
>> In that case the "spin" part of spinlock just burns time & electrons.
>> The "lock" part obviously can't be omitted. Calling straight through
>> to the kernel is the most efficient thing to do.
>
> I see. Is this an issue you've actually hit? I don't see any obvious
> way to make this decision at runtime that doesn't incur unwanted costs
> or failure modes, and I suspect we're spinning way too many times
> anyway even for SMP (i.e. the ideal solution might just be
> significantly reducing the # of spins).
I haven't measured the performance impact of it.
One option could be to configure the number of spins at compile time
and set to zero for known uniprocessor architectures (like armv7m). Or
have a configure override. Really this is just performance tuning,
there's no danger of generating incorrect code.
I can't find a way of detecting a SMP kernel other than parsing the
result of uname(2) which sucks. I was hoping there might be something
in auxv hwcap.
Patrick
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
