Hi Jean, Rudolf, > 1* It requires that we modify each driver individually. It's quite a > shame that we have to update drivers all around the kernel tree with > specific code to workaround a problem which is originally located in a > single place (the ACPI subsystem.) That being said this isn't a blocker > point, if this is the only way, we'll do it. But that's a rather great > amount of work. These additions to drivers might help with the kernel virtualization. > 2* It seems to incur a signficant performance penalty. > ____request_resource isn't cheap as far as I know. And in the > absence of conflict, you are even allocating and releasing the resource > on _each_ I/O operation, which certainly isn't cheap either. Again, it > is not a blocker point, after all this is a workaround for an improper > behavior of the acpi subsystem, this performance penalty is the price to > pay. But there is also a performance penalty for legitimate I/O access, > which worries me more. I thought Rudolf's patch allocated the resource in the driver (w83627ehf) and ACPI contacted the driver when it could not allocate the resource. Since ACPI never *really* wants to allocate the resource, is there a fast-path check it could do? This would help performance. > 3* What about concurrent accesses from ACPI itself? Unless we have a > guarantee that only one kernel thread can run AML code at a given > moment, I can imagine a conflict happening, as your code protects us > well against ACPI and driver concurrent accesses, but not against two > concurrent ACPI accesses. But I'm not familiar with ACPI - maybe we do > have this guarantee? OTOH, if this ever happens, well, it would happen > even without your code. All of ACPI uses the same "virtualized" access mechanism, so even if two threads are poking at the bank select register in a race condition (that would be awful code, I think) they would see the same virtual behavior. > So for now I tend to think that the idea of a global AML lock proposed > by Pavel Machek and Bodo Eggert would be more efficient. And it > wouldn't need any driver-specific code, so it would be much more simple > to implement. The drawback being that we serialize more than we really > need to (e.g. the hardware monitoring driver will not be allowed to > access the chip when _any_ AML code is running, not just when the AML > code accesses the hardware monitoring chip, and if two drivers want to > check the AML lock, they'll exclude each other as well.) But I wonder > if this is a problem in practice. Maybe we'll have to make some > profiling on both solutions and compare. I like the virtualized driver method (if it wasn't obvious!) but the global AML lock works also. It will be interesting to see profiling of both solutions. David
