Messages in this thread | | | From | (H. Peter Anvin) | Subject | Re: spin_unlock optimization | Date | 3 Mar 2000 14:07:59 -0800 |
| |
Followup to: <7715.946598125@ocs3.ocs-net> By author: Keith Owens <kaos@ocs.com.au> In newsgroup: linux.dev.kernel > > > >Erm, spin_unlock is inlined isn't it? So that won't work unless you want to > >grep for the code sequence all over the kernel and modules; also, the binary > >module people would be forced to brutally murder you :-) > > It is technically possible to automate this, using the same trick as > copy_from_user. spin_unlock generates worst case code and stores the > start and end of the code in yet another ELF section. Kernel boot code > decides which version to use, runs the data in the new ELF section and > patches the code before starting the second processor. insmod does the > same thing. Cost is extra storage in zImage and modules, the extra > section would be discarded after loading so it does not bloat the > running kernel. Binary modules (yuck) compiled with the old > spin_unlock would not have the optimized code but they would still > work. >
It's much easier than that. In the actual code you put a trapping instruction, such as INT 70h (and, of course let the INT 70h handler have a kernel-only ring bracket!) followed by a suitable number of NOPs. At trap time, this gets replaced by the suitable code before IRET.
I doubt this is a good idea.
-hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |