Re: s_lock() seems too aggressive for machines with many sockets

From: Nils Goroll <slink(at)schokola(dot)de>
To: Andres Freund <andres(at)anarazel(dot)de>, Jan Wieck <jan(at)wi3ck(dot)info>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: s_lock() seems too aggressive for machines with many sockets
Date: 2015-06-10 14:12:05
Message-ID: 557845B5.1010501@schokola.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/06/15 16:05, Andres Freund wrote:
> it'll nearly always be beneficial to spin

Trouble is that postgres cannot know if the process holding the lock actually
does run, so if it doesn't, all we're doing is burn cycles and make the problem
worse.

Contrary to that, the kernel does know, so for a (f|m)utex which fails to
acquire immediately and thus needs to syscall, the kernel has the option to spin
only if the lock holder is running (the "adaptive" mutex).

Nils

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2015-06-10 14:12:16 Re: reaper should restart archiver even on standby
Previous Message Tom Lane 2015-06-10 14:09:38 Re: "could not adopt C locale" failure at startup on Windows