On Wed, May 18, 2005 at 11:47:23AM +0200, Bodo Stroesser wrote:
I also thought about not saving FP-regs on each kernel entry. But if you do
this optimization, you need to save / restore FP-regs on switch_to. Also you
need to get the FP-regs when setting up a signal-handler stackframe. And they
have to be restored on sys_(rt_)sigreturn from the values found in the
stackframe.
True, but these are much less frequent than kernel entries/exits.
Yes, so it makes sense to optimize this for i386 and x86_64.
On s390, I'm not sure, what to do. Using s390's PTRACE_PEEK/POKEUSR_AREA UML can read or write all regs including FP in a single ptrace call. So, the change would speed up that call a bit, but would that be enough to pay the cost of additional ptrace calls in switch_to or signal handling?
What do you think?
Bodo
I hope, I didn't miss some other places that would need adaption.
Offhand, this sounds right.
Jeff
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
