From owner-freebsd-current@freebsd.org Fri Dec 16 03:10:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB10EC82148 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8B854A06 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8AE56C82147; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A891C82146 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5871AA05 for ; Fri, 16 Dec 2016 03:10:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id n204so9847669qke.2 for ; Thu, 15 Dec 2016 19:10:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=a1lIm9LSxI0OjAtRg8uGFsgDuSy6XuLjXFPYHFBnzSg=; b=L0dVmjM6xcZ6S0/WaDrNx6s9AYUpgakm2JorRYCnbsFEtgTYfMAaTw9d5aBUuLxgcp 9yV7ph8tPiBC3ZfP/4AiWw/VJ5DItY2XEa5eonU1XBmbqHpb3DYtPDF/QfCpfn8OE4uO Y42CtAz8Nwj507y+jU3LqMmYvfNzIPCnHrUti66+3a8e2gn66IvC10cnjlVKFDJdk/sy 9kbznEFwKXBsTju/9I0c8sr4+Vi7bfzuB+6UdS0egdg2pAdp4PGDeUIudV0mlu5otr13 YgWCUfZz/Rh1X3ut42aG04qAzGzVKGngo4CrBb0OXCfRXChV9j58e5QX8P+Bj6mQP8oe 4iMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=a1lIm9LSxI0OjAtRg8uGFsgDuSy6XuLjXFPYHFBnzSg=; b=DyCb321TwEYrix5wntXOGeyr0tUDzzP+Y9Ul9Tp+f8w3cATCsT1bIXMLEOqMULFkMe ZulIDzQYXvBZz4oA8PiA/8QNMc+XRN78U7Welsd/NEeeiLC1lvT8JrYjk3sYv8DpHOlK gSUXjgXaUKY5l5XRKINbYG7L3Gb+bdV8KK92eIDuGOn0q8TIcehlw+PcAHsbaQzb1dVZ Y9Obh/zE1vbe2qi9fYmbX5wYRzeLyqvq/Al8YnmLMoVLgyKJv3IQukD6AZyDrVZouJZD YDXmTIisyZjMaoiMWxi8Nle65uVhO5AF31MgccIyy4N65zzCnzou/mPlVqiFapmDqRrX t0+w== X-Gm-Message-State: AIkVDXL+MrOd5iqvDTJDxg1DspL2qrIc7zfH4wetZu9/GlEHGYtDCs+PEzt8ctLIOax3QxkIpW6KeH+hQKm2nw== X-Received: by 10.55.12.19 with SMTP id 19mr819670qkm.100.1481857807267; Thu, 15 Dec 2016 19:10:07 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.12.181.208 with HTTP; Thu, 15 Dec 2016 19:10:06 -0800 (PST) In-Reply-To: <20161216021719.GA63374@onelab2.iet.unipi.it> References: <20161216021719.GA63374@onelab2.iet.unipi.it> From: Alan Somers Date: Thu, 15 Dec 2016 20:10:06 -0700 X-Google-Sender-Auth: stjWywJT2FvaAhoL_ANm1gcJhB4 Message-ID: Subject: Re: best approximation of getcpu() ? To: Luigi Rizzo Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 03:10:08 -0000 On Thu, Dec 15, 2016 at 7:17 PM, Luigi Rizzo wrote: > TL;DR; is there any way a userspace thread in FreeBSD can tell > on which CPU it is (was) running ? I know the thread can migrate > at any time but as long as the event is rare I can live with > the occasionally wrong information. > Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3), > but the linuxulator in FreeBSD only has a dummy (uniplemented) > function for that syscall. > > FULL DESCRIPTION > It is common practice, when building scalable systems, to use per-cpu > resources that can be accessed without contention by just protecting > them with a CLI; STI; pair. Multiqueue NICs typically do this to > build a lock-free transmit path. In [1] we show an in-kernel > scheduler that maps a large number of clients to a (much smaller) > number of lock-free mailboxes, one per core. > > In the kernel we can do CLI and STI and access curcpu. > In userspace a suitably privileged process can indeed open /dev/io > to acquire the right to use CLI and STI, though I am not sure > wether curcpu is available in some way. > > Of course running userspace code with interrupts disabled is risky, > but we can use the per-cpu trick with a small tweak, namely, > protect each resouce with a lock. If the thread does not migrate > imediately after getcpu(), we will access the lock (and the resource) > almost always from the same cpu hence very efficiently. > Occasional migration may cause contention but should not > alter too much the good performance of this scheme. > > So, any idea before I add a syscall/ioctl (or extend one) > to export this information ? > > thanks > luigi > > > [1] http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf 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. -Alan