Message-ID: <bd961cb2-20fb-40ec-82b0-abcf32a787bb@iki.fi>
Date: Mon, 2 Dec 2024 12:42:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Interrupts vs signals
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Robert Haas
 <robertmhaas@gmail.com>, Fujii Masao <masao.fujii@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Andres Freund <andres@anarazel.de>
References: <CA+hUKGJACzP++3PifHTMgG2xgTD4irap6+CXBMogKKiD43VqoA@mail.gmail.com>
 <CA+hUKGLAZCxzyhyoYz0BmGkqkmj-38ZfToF1GqNYhU+Br+XCLQ@mail.gmail.com>
 <3b996d73-2a10-4072-a58d-0386af0cbb78@iki.fi>
 <CA+hUKGJvt8wg_KfjFLvr27LT6sYK_szngkchig6Dg_CnNGPskw@mail.gmail.com>
 <46f047a1-bfd5-406a-a0f3-97205d9529ad@iki.fi>
 <476672e7-62f1-4cab-a822-f3a8e949dd3f@iki.fi>
 <CA+hUKG+6rn1FNxvO7Wuz_aAQ4MnGW5G6+UW4nBnzwnGnuBVWyw@mail.gmail.com>
 <391abe21-413e-4d91-a650-b663af49500c@iki.fi>
 <b3930251-78d5-4379-b213-b37b469f6dfb@iki.fi>
 <CA+TgmoZQK2HfGqz3py1TaiQ3-NiVwYK4+ZTWGnm6z41mHeAksA@mail.gmail.com>
 <ZyLQEG1KfCts3N_3@paquier.xyz> <b697b96e-78b5-49bb-8d66-581143a65d7a@iki.fi>
 <c272c49d-cd7e-4897-aed7-76dc517607fc@iki.fi>
 <CA+hUKGKs+ozrxt_X2FQ=yv5Mx8ZJ2fB+j8yLVZwa13LedT6CSg@mail.gmail.com>
 <8a0ff52f-de8e-49d2-a3af-ea5bc12f5b97@iki.fi>
 <CA+hUKGKroPrwnUvnN0xORPYvXRY-90PC9g_C4suvp9Cws30yAg@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <CA+hUKGKroPrwnUvnN0xORPYvXRY-90PC9g_C4suvp9Cws30yAg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/bd961cb2-20fb-40ec-82b0-abcf32a787bb%40iki.fi>
Precedence: bulk

On 02/12/2024 09:32, Thomas Munro wrote:
> On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>> Hmm, so this would replace the maybeSleepingOnInterrupts bitmask I
>> envisioned. Makes a lot of sense. If it's a single bit though, that
>> means that you'll still get woken up by interrupts that you're not
>> waiting for. Maybe that's fine. Or we could merge the
>> maybeSleepingOnInterrupts and pendingInterrupts bitmasks to a single
>> atomic word, so that you would have a separate "maybe sleeping" bit for
>> each interrupt bit, but could still use atomic_fetch_or atomically read
>> the interrupt bits and announce the sleeping.
> 
> I think one bit is fine for now.  At least, until we have a serious
> problem with interrupts arriving when you're sleeping but not ready to
> service that particular interrupt.  The 'interrupt bit already set,
> don't try to wake me' stuff discussed earlier would limit the number
> of useless wakeups to one, until you eventually are ready and consume
> the interrupt.  The main case I can think of, if we fast forward to
> the all-procsignals-become-interrupts patch (which I'll be rebasing on
> top of this when the next version appears), is that you might receive
> a sinval catchup request, but you might be busy running a long query.
> Sinval catchup messages are only processed between queries, so you
> just keep ignoring them until end of query.  I think that's fine, and
> unlikely.  Do you have other cases in mind?

Yeah, no, I think one bit is is good enough. Let's go with that.

> If there is legitimate use case for a more fine-grained maybe-sleeping
> and I've been too optimistic above, I don't think we should give one
> whole maybe-sleeping bit to each interrupt reason.  We only have 32
> bit atomics (splinlock-based emulation of 64 bit atomics is not good
> enough for this, it's not safe in SIGALRM handlers, at least not
> without a lot more pain; admittedly the SIGALRM handlers should
> eventually be replaced but not for a while) so if we used up two bits
> for every interrupt reason we could handle only 16 interrupt reasons,
> and that's already not enough.  Perhaps we could add maybe-sleeping
> bits for classes of interrupt if we ever determine that one bit for
> all of them isn't enough?

If we run out of bits in a single pendingInterrupt words, we can have 
multiple words. SendInterrupt and ClearInterrupt would still only need 
to manipulate one word, the one holding the bit it's setting/clearing. 
WaitEventSetWait() would need to touch all of them, or at least all the 
ones that hold bits you want to wait for. That seems OK from a 
performance point of view.

I don't think we need to go there any time soon though, 32 bits should 
be enough for the use cases we've been discussing.

-- 
Heikki Linnakangas
Neon (https://neon.tech)