On Fri, Jul 1, 2016 at 9:51 AM, Masao Uebayashi <[email protected]> wrote: > On Tue, Jun 28, 2016 at 10:08 AM, Ryota Ozaki <[email protected]> wrote: >> On Sat, Jun 25, 2016 at 11:56 AM, matthew green <[email protected]> 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
