Date: Mon, 8 Jul 2013 00:34:58 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Davide Italiano <davide@freebsd.org> Cc: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Accessing struct pthread from kernel Message-ID: <20130707213458.GH91021@kib.kiev.ua> In-Reply-To: <CACYV=-H_T98QPWOLS=0iHxgt1Om-sR3p8ogqFCsZHFiZDLtosg@mail.gmail.com> References: <CACYV=-H_T98QPWOLS=0iHxgt1Om-sR3p8ogqFCsZHFiZDLtosg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--KUl1BpUVukgrQ7uD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: > Hi, > as a preliminary step in the implementation of adaptive spinning for > umtx, I'm switching the pthread/umtx code so that a thread that > acquires a pthread_mutex writes the address of struct pthread in the > owner field of the lock instead of the thread id (tid). This is > because having struct pthread pointer allows easily to access > informations of the thread, and makes easy to get the state of the > thread exported from the kernel (once this will be implemented). >=20 > For what concerns the libthr side, the internal function > _get_curthread() goes into the TLS to obtain the struct field of > curthread, so I'm done. > OTOH, I'm quite unsure instead about how to get address of struct > pthread for curthread from the kernel side (for example, in > do_lock_umutex() sys/kern/kern_umtx.c). You should not, see below. >=20 > I guess I need to write some MD code because the TLS is different on > the various architecture supported in FreeBSD, and as a first step I > focused on amd64. > It looks like from the SDM that %%fs register points to the base of > the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase > (and then adding the proper offset to acces the right field) is a > viable solution to do this. Am I correct? > In particular what worries me is if the read of 'struct pthread' for > curthread from the TLS register is atomic with respect to preemptions. >=20 > Alternatively, is there an (easier way) to accomplish this task? Coupling the libthr thread structure and kernel makes the ABI cast in stone and avoids most possibilities of changing the libthr internals. The same is true for kernel accessing the userspace TLS area of the thread. If you want kernel<->usermode communication of the thread run state, and possibly also a way to advisory prevent a preemption of the spinning usermode thread, you should create a dedicated parameter block communicated from usermode to kernel on thread creation. For the main thread, the block could be allocated by kernel by image activator, placed on the stack and its address passed to the usermode by auxv. Note that you cannot access the usermode from the context switch code. Wiring the corresponding page is very wasteful (think about a process with 10,000 threads) and still does not provide any guarantees since usermode can unmap or remap the range. You might see my 'fast sigprocmask' patches where somewhat similar idea was implemented. I also recommend you to look at the Solaris schedctl(2). --KUl1BpUVukgrQ7uD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR2d8BAAoJEJDCuSvBvK1B2eMP/3wSALXdp5FSZb407N2oD6d/ 9vbhDnwRa5wMt5qzlktX7HSTUMsRjUSMyS7PfR7nLXp6/G5UKfQ/uBMR/R+J5bVs Z8nyIJ6tzE5+sYiAeWOzRI1tYk8K2uaC8lKeDB0NiVg0M1EaBRQMsJ894UJ9bhJq 71EC3YrS/WNl8KJKKZAoWP/ZR/aOtXbqZ7c69A7PC9yLvfp1oxtWbXoEBNNLx+UZ y3zf0TAyaWCpafl78Ftpb8ZGL3LaULR97JDYnachXVP0ATGVchDee10W3D/6FnBT cdI9mQ5hBYcAbC6pAz1gkotBDNeqGau6rneaCosSiehJmpVDTHTBLLey05SW3MWR 0ND9rwoQJvDcpWyPSVFx5ubcYQMXZ5wM1r0Us4znIELy4IXm5PArAnyN5nJVfKx+ SfPUNAAJz8eXybkFufnpdHavqaMyvetBjQ+20VdpI1hxtgIZXE8KHfYpAHl53Ozp pINKqlnZKLScjjWVOcQEHqwSPZYAYIuVBRcuCh23cYteBS5FDr4uGLIHQZ7usP0l Z1LhuVe6y+eMPSosI8AyCl9crcQHHIzTb7utHP9FzHVNXBkDj2XL+XgE1HL9+cEY l1rPg3hBnxyH4yzD8gQnMAJTeWQTUUb89CDT9FLi20YgyiWFpOh/Uh3yfmFc9xan JMA232G6Ic8crBLbFU2i =T71R -----END PGP SIGNATURE----- --KUl1BpUVukgrQ7uD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130707213458.GH91021>