Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: [BENCHMARK] Lmbench 2.5.54-mm2 (impressive improvements) | Date | 5 Jan 2003 16:58:49 -0800 |
| |
Followup to: <Pine.LNX.4.44.0301051040020.11848-100000@home.transmeta.com> By author: Linus Torvalds <torvalds@transmeta.com> In newsgroup: linux.dev.kernel > > Now, that SYSENTER_CS thing is very rare indeed, and by keeping track of > what the previous value was (ie just caching the SYSENTER_CS value in the > thread_struct), we could get rid of it with a conditional jump instead. > Want to try it? >
This seems like the first thing to do.
Dealing with the SYSENTER_ESP issue is a lot tricker. It seems that it can be done with a magic EIP range test in the #DB handler, the range is the part that finds the top of the real kernel stack and pushfl's to it; the #DB handler if it receives a trap in this region could emulate this piece of code (including pushing the pre-exception flags onto the stack) and then invoke the instruction immediately after the pushf..
Yes, it's ugly, but it should be relatively straightforward, and since this particular chunk is assembly code by necessity it shouldn't be brittle.
The other variant (which I have suggested) is to simply state "TF set in user space is not honoured." This would require a system call to set TF -> 1. That way the kernel already has the TF state for all processes.
Again, it's ugly.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> - 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/
| |