> This Spin Lock is defined globally, This causes that my high priority > process to get blocked because of a lower priority process that holds > this spin lock. Of course you get priority inheritance, but this adds > quite a lot of extra execution time to the read function (because of > additional spin lock behavior, and scheduling to the lower priority > process) It's a spin lock and its only held across very small numbers of instructions in any normal path so this rather surprises me - in your actual capture data can you see what is holding the lock for long times causing this ? > Since the "user" and "refcount" reference counters have combined > behavior (refcount is decremented when users reaches zero), I don't > see a way to remove this global lock. Any ideas how this can be > improved? I've never really thought about it because it should never be contended in any meaningful way. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
