Regarding how GPIO interrupts get to ElixirALE, ElixirALE blocks on the poll(2) system call on a special file under the /sysfs directory. When the GPIO pin changes, the poll call unblocks. That’s documented here: linux/Documentation/gpio/sysfs.txt at rpi-4.14.y · raspberrypi/linux · GitHub.
As for how Linux knows to update that file, that’s documented in the GPIO section of the processor’s datasheet here: https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2835/BCM2835-ARM-Peripherals.pdf. It looks like the code of interest is here: linux/drivers/pinctrl/bcm/pinctrl-bcm2835.c at rpi-4.14.y · raspberrypi/linux · GitHub. At the very least, you can see how all GPIO pins share 2 or 3 interrupt lines inside the processor, so Linux has to figure out what happened whenever one changes.
I think that your barometer should fine since it doesn’t sound like it has a high interrupt rate. I’m not sure what the real threshold is, but if I were looking at a >100Hz interrupt rate, I’d look at alternatives to handling the interrupts with ElixirALE.
