Date: Wed, 19 Feb 2014 18:01:59 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Warner Losh <wlosh@bsdimp.com> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: [RFC] Enable use of UserLocal Register (ULRI) if detected (patches) Message-ID: <alpine.BSF.2.00.1402191759170.24900@fledge.watson.org> In-Reply-To: <092B0786-EA73-44D0-81FC-DFB56B14D4D7@bsdimp.com> References: <D964DBB1-3727-4B8A-B4E3-50FD8A300818@FreeBSD.org> <092B0786-EA73-44D0-81FC-DFB56B14D4D7@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Feb 2014, Warner Losh wrote: >> For more information about the ULRI see "MIPS Architecture for Programmers >> Volume III" section 9.9 UserLocal Register (CP0 Register 4, Select 2). > > Thanks for doing this! I would note, BTW, that the current use of TLS in malloc()/free() and today's MIPS exception handler for TLS implementation do introduce a very measurable overhead. I'm left wondering if there is something we can do for unthreaded processes to avoid taking kernel traps on every memory allocation and free for MIPSes without ULRI. (Note that that problem is present before Stacey's patch: the reason we added ULRI support is that our hardware does support ULRI, and we can therefore avoid that nasty overhead ...) I understand there's work on a new MIPS ABI that specifies a TLS register not requiring a trap to read on non-ULRI hardware, but I'm not sure how far that is from being available. Certainly it will require compiler/OS/etc work before it becomes useful to us. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1402191759170.24900>