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