On Sat, 2008-09-27 at 09:37 +0400, Alexey Starikovskiy wrote: > Zhao Yakui wrote: > > Of course such laptops can still work well except that CPU > > interrupt will be disabled for some extra time after Alexey's patch is > > applied .(The some extra time depends on how many EC Inb/out operations > > are executed). > > > > > spinlock is released after each I/O, so by your own calculation > it is disabled for 1.5 usec. Yes. The CPU interrupt is disabled for about 0.7usec while doing every EC I/O access.(Inb/outb). This affect is very tiny. But when the time is accumulated for many EC I/O access, it seems that the CPU will be disabled for longer time. > You can then multiply this number by lifetime of the universe, > it does not mean anything. > > Regards, > Alex. > > In my email the purpose that I point out 2000 EC I/O read/write > > operation doesn't indicate that 2000 EC I/O read/write will be executed > > per second. What I want to say is that EC I/O read/write is slow > > operation. If quite a lot of EC I/O read/write are accessed for some > > reasons in some time, the CPU interrupt will be disabled for a long > > time. In such case the normal laptop will be affected by this. (Of > > course maybe the affect will be very tiny). > > In fact in kernel source code if the race can be resolved by other > > synchronization protection mechanism, the spin_lock had better be > > avoided. > > > Please explain, I'd like to make poster of it :) As in the current patch the gpe_transaction is accessed in the two different routines(Control thread, Interrupt-context), spin_lock is necessary to prevent the race. I agree with what you have done. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
