Date: Fri, 27 Mar 2009 17:25:52 -0700 From: Jason Evans <jasone@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Sergey Babkin <babkin@verizon.net>, freebsd-hackers@FreeBSD.org, attilio@FreeBSD.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com Subject: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) Message-ID: <49CD6E90.6050303@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.0903280006510.12518@fledge.watson.org> References: <7362.1238195438@critter.freebsd.dk> <alpine.BSF.2.00.0903280006510.12518@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > On Fri, 27 Mar 2009, Poul-Henning Kamp wrote: >> In message <alpine.BSF.2.00.0903272303040.12518@fledge.watson.org>, >> Robert Wats on writes: >> >>> In which case user application threads will need to know their CPU [...] >> >> Didn't jemalloc solve that problem once already ? > > I think jemalloc implements thread-affinity for arenas rather than > CPU-affinity in the strict sense, but I may misread. CPU affinity is of limited use to malloc unless it can safely pin threads to CPUs. Unfortunately, malloc cannot muck with CPU affinity, since that's up to the application. Therefore, as you say, jemalloc implements (dynamically balanced) arena affinity. It might work okay in practice to use the current CPU ID to decide which arena to use, if the scheduler does not often migrate running processes. I haven't explored that possibility though, since the infrastructure for cheaply querying the CPU ID doesn't currently (to my knowledge) exist. Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49CD6E90.6050303>