Date: Fri, 11 Apr 2003 16:54:51 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Julian Elischer" <julian@elischer.org>, "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving Message-ID: <040c01c30008$03590590$f001a8c0@davidw2k> References: <Pine.BSF.4.21.0304102351360.94222-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20 From: "Julian Elischer" <julian@elischer.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: "Peter Wemm" <peter@wemm.org>; "David Xu" <davidxu@freebsd.org>; = <freebsd-threads@freebsd.org> Sent: Friday, April 11, 2003 2:54 PM Subject: Re: patch for %gs saving=20 >=20 >=20 > On Fri, 11 Apr 2003, Daniel Eischen wrote: >=20 > > On Thu, 10 Apr 2003, Peter Wemm wrote: > >=20 > > > "David Xu" wrote: > > > > Here is the patch for kernel to save %gs, > > > > it works well on my machine. > > > > http://people.freebsd.org/~davidxu/i386_gs.diff > > > > Daniel, is this the reason in your libpthread > > > > patch that doesn't use getcontext syscall ? > > >=20 > > > To put some background on the issue, there is a reason why we did = not > > > do this. %gs is not used by the kernel, so it does not normally = need to > > > be saved and restored on every trap into the kernel. Setting a = segment > > > register is Really Slow - measured in hundreds of clock cycles. > > >=20 > > > So, we normally only touch %gs when we context switch to a = different process > > > that may have a different %gs. Or when one of the context = syscalls wants > > > it changed. We cannot avoid touching %fs because we use it for = kernel > > > private data. But if it wasn't for that, we wouldn't be touching > > > %fs for regular traps/syscalls/etc either. > > >=20 > > > Bruce Evans understands this better than I do, I would suggest not = making > > > this change without talking about it with him first. > >=20 > > BTW, it's not really a big deal for the UTS to restore %gs > > (or probably whatever it ends up being on other archs) before > > continuing a thread. >=20 > I put it to you that %gs should be a way of finding the current KSE > mailbox > (upcall mailbox) which will NOT CHANGE when a thread is changed in > userland. one simply changes the curthread pointer in the KSE (upcall) > mailbox, leaving %gs the same. >=20 > %gs should never change for a single KSE as it goes in and out of the > kernel, it must always have the same mailbox. >=20 >=20 Yes, I saw some code in libpthread patch changes %gs, for example thr_switch(), thr_enter_uts(), I think such code=20 needn't change %gs, and I think even %fs, %ds, %es is needn't to be changed, this would speedup context switch. >=20 > >=20 > > --=20 > > Dan Eischen > >=20 > > _______________________________________________ > > freebsd-threads@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > > To unsubscribe, send any mail to = "freebsd-threads-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?040c01c30008$03590590$f001a8c0>