public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Andres Freund <[email protected]>
Subject: Re: Interrupts vs signals
Date: Mon, 2 Dec 2024 12:42:20 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGKroPrwnUvnN0xORPYvXRY-90PC9g_C4suvp9Cws30yAg@mail.gmail.com>
References: <CA+hUKGJACzP++3PifHTMgG2xgTD4irap6+CXBMogKKiD43VqoA@mail.gmail.com>
<CA+hUKGLAZCxzyhyoYz0BmGkqkmj-38ZfToF1GqNYhU+Br+XCLQ@mail.gmail.com>
<[email protected]>
<CA+hUKGJvt8wg_KfjFLvr27LT6sYK_szngkchig6Dg_CnNGPskw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+hUKG+6rn1FNxvO7Wuz_aAQ4MnGW5G6+UW4nBnzwnGnuBVWyw@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmoZQK2HfGqz3py1TaiQ3-NiVwYK4+ZTWGnm6z41mHeAksA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+hUKGKs+ozrxt_X2FQ=yv5Mx8ZJ2fB+j8yLVZwa13LedT6CSg@mail.gmail.com>
<[email protected]>
<CA+hUKGKroPrwnUvnN0xORPYvXRY-90PC9g_C4suvp9Cws30yAg@mail.gmail.com>
On 02/12/2024 09:32, Thomas Munro wrote:
> On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas <[email protected]> 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)
view thread (22+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Interrupts vs signals
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox