I have a book statement:
Disabling interrupt is time-consuming in multi-processor system.
I suspect that this is related to the hardware implementation of how interrupt is enabled/disabled. So what's the mechanism behind it?
[Note: I read your question too quickly when I started answering, and didn't notice that you specified "multi-processor system". I'm leaving in the first part, which is also relevant to single-processor systems, in case it's interesting. :-)]
Modern processors are 'pipelined', meaning that they have more than one instruction running at the same time. Disabling interrupts is a change to the way the processor is handling instructions, so it can't happen while there are instructions being executed. So the pipeline has to be "flushed", completing all in-flight instructions, before the processor can proceed to turn off interrupts. The deeper the pipeline, the longer this takes; modern pipelines are very deep (up to 25 stages according to https://softwareengineering.stackexchange.com/questions/210818/how-long-is-a-typical-modern-microprocessor-pipeline .)
There's an interesting discussion here that's worth reading, although it's about 15 years old: https://comp.os.linux.development.system.narkive.com/Y6xfETFN/why-disabling-enabling-interrupts-is-expensive-operation .
According to https://www.halolinux.us/kernel-reference/global-interrupt-disabling.html , disabling interrupts across all CPUs on a multi-processor system is no longer normally done on Linux (because it slows down the whole system). But there's a good discussion there of the steps involved. Most notably, it requires waiting for any existing interrupts (and some related code) on other CPUs to complete before it can proceed. It's not directly discussed there (although it's mentioned in the previous link), but I believe this also involves making an "inter-processor interrupt" to each other CPU, which is itself a slow process, requiring the requesting processor to pause while it waits for each other processor to stop what it's doing and respond to the request.
As you can see, the details of an operation like this can get very complex under the covers. The absolute best way to determine something like this -- how long a particular operation takes, or generally what real system behavior is like -- is always to test it on real systems, if you want to know for sure.