Date: Wed, 04 Mar 2015 10:29:27 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: Harrison Grundy <harrison.grundy@astrodoggroup.com> Subject: Re: Minor ULE changes and optimizations Message-ID: <1843154.4TcuH8bhtB@ralph.baldwin.cx> In-Reply-To: <54F4DE0D.7070606@astrodoggroup.com> References: <54EF2C54.7030207@astrodoggroup.com> <5490895.NN1ciTh6gZ@ralph.baldwin.cx> <54F4DE0D.7070606@astrodoggroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1843154.4TcuH8bhtB>