Messages in this thread | | | Date | Mon, 5 Mar 2007 13:35:20 -0800 | From | "David Hubbard" <> | Subject | Re: [lm-sensors] Could the k8temp driver be interfering with ACPI? |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |