Re: Introduce curlwp_bind and curlwp_unbind for psref(9)

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Fri, Jul 1, 2016 at 9:51 AM, Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> On Tue, Jun 28, 2016 at 10:08 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>> On Sat, Jun 25, 2016 at 11:56 AM, matthew green <mrg%eterna.com.au@localhost> wrote:
>>>> > Since we already use preempt_disable() to force an lwp to stick to a cpu,
>>>> > doesn't that solve the problem?  If need be, we can enforce nonpreemptable
>>>> > lwp's don't migrate.
>>>
>>> why would we want to disable preemption in code that merely wants
>>> to run on a particular cpu.
>>>
>>> i dno't understand why using the side effect of preempt_disable()
>>> is better than  explicitly stating what is wanted.
>>
>> Yes. That's why the API is introduced.
>
> And by introducing such a primitive function, you're doubling the
> number of combinations of primitives...
>
> I hope (some of) you surely understand all the implications of those
> combinations ... but I'm not.  I'm even not sure if kpreempt_disable()
> really prevents LWPs from migrating between CPUs.  It'd be really
> helpful if restrictions are expressed by *strict* assertions.
>
> Could you at least put KASSERT((l->l_pflags & LP_BOUND) == 0) in curlwp_bind()?

The assertion is invalid because curlwp_bind can be used regardless of
if LP_BOUND is set or not; it just makes sure LP_BOUND is set and restore
the original state in curlwp_bindx, just like spl*/splx do.

  ozaki-r