From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 18 19:58:24 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A65EA8FE; Tue, 18 Feb 2014 19:58:24 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 74C761D67; Tue, 18 Feb 2014 19:58:24 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 911BBB93B; Tue, 18 Feb 2014 14:58:23 -0500 (EST) From: John Baldwin To: Andrey Chernov Subject: Re: can the scheduler decide to schedule an interrupted but runnable thread on another CPU core? What are the implications for code? Date: Tue, 18 Feb 2014 14:42:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <20140215001100.GS34851@funkthat.com> <52FED14E.50304@freebsd.org> In-Reply-To: <52FED14E.50304@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Message-Id: <201402181442.36380.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 14:58:23 -0500 (EST) Cc: "freebsd-hackers@freebsd.org" , Andriy Gapon , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 19:58:24 -0000 On Friday, February 14, 2014 9:30:38 pm Andrey Chernov wrote: > On 15.02.2014 4:11, John-Mark Gurney wrote: > >>> This is code example from cpuminer port, in case you are interested, it is very simple: > >>> > >>> static inline void affine_to_cpu(int id, int cpu) > >>> { > >>> cpuset_t set; > >>> CPU_ZERO(&set); > >>> CPU_SET(cpu, &set); > >>> cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_CPUSET, -1, sizeof(cpuset_t), &set); > >> > >> I think that CPU_WHICH_TID should have been used here. > > > > I agree... cpuset(2): > > The which argument determines how the value of id is interpreted and is > > of type cpuwhich_t. The which argument may have the following values: > > > > CPU_WHICH_TID id is lwpid_t (thread id) > > CPU_WHICH_PID id is pid_t (process id) > > CPU_WHICH_CPUSET id is a cpusetid_t (cpuset id) > > CPU_WHICH_IRQ id is an irq number > > > > An id of '-1' may be used with a which of CPU_WHICH_TID, CPU_WHICH_PID, > > or CPU_WHICH_CPUSET to mean the current thread, process, or current > > thread's cpuset. All cpuset syscalls allow this usage. > > The question still remains: why SCHED_ULE and SCHED_4BSD do different > things here on CPU_WHICH_CPUSET == -1 (current thread's cpuset)? It > looks like SCHED_ULE changes per/process mask while SCHED_4BSD change > per/thread mask in that case. Eh, no. CPU_WHICH_CPUSET changes the global set that the thread belongs to. t is not per proceses or per thread. Unless you are explicitly creating new global sets, your thread belongs to the default set (set 1), and this call is changing the default set (set 1) to only use a single CPU. This affects all processes in the machine that do not have their own sets. -- John Baldwin