From owner-freebsd-arch@FreeBSD.ORG Wed Mar 4 16:23:27 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 085182C3 for ; Wed, 4 Mar 2015 16:23:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4631BBC for ; Wed, 4 Mar 2015 16:23:26 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A952AB926; Wed, 4 Mar 2015 11:23:25 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Minor ULE changes and optimizations Date: Wed, 04 Mar 2015 10:29:27 -0500 Message-ID: <1843154.4TcuH8bhtB@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54F4DE0D.7070606@astrodoggroup.com> References: <54EF2C54.7030207@astrodoggroup.com> <5490895.NN1ciTh6gZ@ralph.baldwin.cx> <54F4DE0D.7070606@astrodoggroup.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 04 Mar 2015 11:23:25 -0500 (EST) Cc: Harrison Grundy X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 16:23:27 -0000 On Monday, March 02, 2015 02:02:53 PM Harrison Grundy wrote: > > But why would a driver want to do that? This code: > > sched_pin(td); > > > > /* do something */ > > > > thread_lock(td); > > sched_unpin(td); > > sched_bind(td, PCPU_GET(cpuid)); > > thread_unlock(td); > > > > /* do something else */ > > > > thread_lock(td); > > sched_unbind(td); > > thread_unlock(td); > > > > Is equivalent to: > > sched_pin(td); > > > > /* do something */ > > > > /* do something else */ > > > > sched_unpin(td); > > > > But the latter form is lighter weight and easier to read / understand. > > > > Letting you sched_bind() to the current CPU while you are pinned doesn't > > enable any new functionality than you can already achieve by just using > > sched_pin() and sched_unpin(). > > The difference between the two is that TSF_BOUND is set for "do > something else" in the former case. > > As I understand the difference, sched_pin is designed for temporarily > assigning to a CPU, while sched_bind is intended for longer-term affinity. sched_bind() calls sched_pin() internally, so that isn't the difference. The flag only exists to know which type of pinning is in force. The differences are that sched_pin() assumes the current CPU rather than a specific CPU and that it can nest, whereas sched_bind() is used to move a thread to a specific CPU and it cannot nest. It is true that one cannot bind a pinned thread, but that is because the semantics conflict, not because one is longer term than the other. You can't return from a system call using either sched_bind or sched_pin for example. For a longer term binding you need to set the thread's cpuset instead. sched_pin() and sched_bind() are both "short term" in that regard. > The patch would allow you to set the bound flag without unpinning, > basically. It seems easier to do this here, than add a "set bound flag" > function that allows drivers to "promote" themselves from pinned to > bound, though that would also be an option to get to the same place. I don't see a use case for why a driver would want to do this. Do you have a specific real world use case in mind? -- John Baldwin