Messages in this thread | | | Date | Mon, 05 Jul 2010 16:12:43 -0700 | From | Jeremy Fitzhardinge <> | Subject | Re: [PATCH 2/4, v2] x86: enlightenment for ticket spin locks - Xen implementation |
| |
On 06/30/2010 03:14 PM, H. Peter Anvin wrote: > On 06/30/2010 06:23 AM, Jeremy Fitzhardinge wrote: > >> pvops is a superset of alternative instruction patching, and are really >> designed to serve different purposes. There are some areas in which >> there's some overlap, but otherwise they are distinct. In particular, >> alternative instructions are really only useful if you can express the >> patch in terms of the presence or absence of a particular cpu feature. >> It can't do multi-way choice, and it can't do anything other than insert >> literal instructions. pvops patching can do multi-way, and has a >> higher-level view of each patch site which allows it to do things like >> generate appropraite save/restores, make inline vs call decisions, nop >> out nop callsites, etc. >> >> > A lot of this -- in particular the multiway -- is a defect in the > alternatives implementation and should have been addressed as such.
The pvops and asm alternatives have different design goals. Asm alternatives is all about replacing particular instructions with different ones depending on the properties of the CPU. pvops is about inserting an ops vector in front of various OS-level interfaces to allow alternate implementations; the patching part was a later optimisation sprinkled on top to reduce the abstraction overhead. The fact that there's some similarity in mechanism is the result of convergence rather than a desire to reinvent.
> One > of the biggest problems with pvops as it currently stands is that it is > monolithic; in general we have this class of problems (static selection) > in a *lot* more places than we're dealing with right now, and as such, > generalizing *something* -- be it pvops or alternatives -- would be useful. >
Yes. The module system might also be a candidate for making more general (by allowing the kernel to have unbound references, and the module system can be used to create a runtime binding). Modules are already arch neutral (the arch-specific bits), which is an improvement over alternatives or pvops, but it has no notion of patching anything beyond linker relocs (but aside from very hot-path pvops such as interrupt enable/disable, instruction patching isn't used all that much).
> gcc 4.5 also includes a very powerful facility called "asm goto", which > I have already used to implement static_cpu_has(). Again, that > particular construct (unlike "asm goto" itself) doesn't support multiway. >
What does the fallback for older compilers look like?
J
| |