On 16 December 2016 at 11:45, Luigi Rizzo <ri...@iet.unipi.it> wrote:
> On Fri, Dec 16, 2016 at 09:29:15AM +0000, David Chisnall wrote:
>> On 16 Dec 2016, at 03:10, Alan Somers <asom...@freebsd.org> wrote:
>> > What about pthread_setaffinity(3) and friends? You can use it to pin
>> > a thread to a single CPU, and know that it will never migrate.
>> This is not a useable solution for anything that needs to live in a library
>> and also doesn???t solve the problem.
>> The Linux get_cpu call() is used for caches that are somewhere between
>> global and thread-local. Accessing them still requires a lock, but it???s
>> very likely to be uncontended (contention only happens when you???re context
>> switched at exactly the wrong time, or if a thread is migrated between cores
>> in between the get_cpu() call and usage) and so you can use the userspace
>> fast path for the lock and not suffer from cache contention effects.
>> One x86, you can use cpuid from userspace and get the current core ID. I
>> have some code that does this and re-checks every few hundred accesses,
>> storing the current CPU ID in a thread-local variable. Using the per-CPU
>> caches is a lot faster than using the global cache (and reduces contention
>> on the global cache). It would be great if we could have a syscall to do
>> this on FreeBSD (it would be even better if we could have specify a TLS
>> variable that the kernel automatically updates for the userspace thread when
>> the scheduler migrates the thread between cores).
> indeed the following line seems to do the job for x86
> asm volatile("cpuid" : "=d"(curcpu), "=a"(tmp), "=b"(tmp), "=c"(tmp)
> : "a"(0xb) );
> (there must be a better way to tell the compiler that eax, ebx, ecx, edx are
> all clobbered).
> 0xb is the CPUID function that returns the current APIC id for the
> core (not necessarily matching the OS core-id)
> The only problem is that this instruction is serialising and slow,
> seems to take some 70-100ns on several of my machines so you
> cannot afford to call it at all times but need the value cached
> somewhere. Exposing it as thread local storage, or a VDSO syscall,
> would be nicer because the kernel knows when it is actually changing
The problem is your CPU ID can change in the middle of packet handling.
So if you want it to be accurate, you need to bind your worker thread to a CPU.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"