Re: Interrupts vs signals

On 02/12/2024 09:32, Thomas Munro wrote:
> On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas <hlinnaka(at)iki(dot)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)