[erlang-bugs] Dirty schedulers and '-smp disable'

[Steve Vinoski]

On Tue, Dec 1, 2015 at 9:04 PM, Paul Davis <paul.joseph.davis@REDACTED>
wrote:

> I just butted up against this as well. Testing some code on a single
> core virtual box vm and wasn't used to smp being disabled by default.
> I've reproduced the behavior exactly as Knut described.
>
> One thing further that was also icky is that the ErlNifSysInfo struct
> has the dirty_scheduler_support flag set to 1 even when dirty
> schedulers don't work (due to smp being disabled on single core VMs).
> Thus, if you want to be super duper certain you have to check that
> smp_support is enabled as well. While not a terrible inconvenience
> once you know about it, I definitely managed to spend two hours
> figuring it out.
>

That too seems like a bug, for now anyway.

Only the OTP team can authoritatively state the plans for dirty schedulers,
but I'm still involved in working on them and my understanding is there's a
push to get them out of experimental status and into regular feature status
for Erlang 19. Part of that push includes an effort to make them work even
if SMP is disabled.

--steve



>
>
> On Wed, Jul 1, 2015 at 4:25 AM, Knut Nesheim <knutin@REDACTED> wrote:
> > Yes, your answer makes sense.
> >
> > Just to clarify, the VM has been built with smp support, but when it
> > boots up on a single-core machine it doesn't enable smp because it
> > only detects one logical processor. I was able to reproduce the "dirty
> > nif stuck" problem with "erl -smp disable".
> >
> > Knut
> >
> > On Tue, Jun 30, 2015 at 5:06 PM, Steve Vinoski <vinoski@REDACTED> wrote:
> >>
> >>
> >> On Tue, Jun 30, 2015 at 10:39 AM, Knut Nesheim <knutin@REDACTED>
> wrote:
> >>>
> >>> Dear list,
> >>>
> >>> I ran into unexpected behaviour in the following situation:
> >>>
> >>>  * OTP 18.0, compiled from the git tag with dirty schedulers enabled
> >>>  * NIF with the ERL_NIF_DIRTY_JOB_CPU_BOUND flag
> >>>  * Small machine with only one core (AWS t1.micro)
> >>>  * The first log line from startup with no explicit flags looks like
> >>> this: Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10]
> >>> [hipe] [kernel-poll:false]
> >>>
> >>> When I call the NIF, the calling process hangs forever. When I call it
> >>> from the shell, I'm unable to interrupt the process (C-g, i 1 does
> >>> nothing useful).
> >>>
> >>> If I explicitly use '-smp enable' as arguments to erl, the NIF runs
> >>> fine. In that case the first log line looks like this: Erlang/OTP 18
> >>> [erts-7.0] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:10]
> >>> [hipe] [kernel-poll:false]
> >>>
> >>> This behaviour got me a bit confused, as there is no indication what
> >>> is happening except "something somewhere got stuck". It's not a common
> >>> case for me, as most machines have multiple cores except tiny cloud
> >>> instances or virtual machines.
> >>
> >>
> >> The short answer is that currently, dirty schedulers always require SMP.
> >>
> >> The longer answer is that configure should raise an error if this
> >> configuration is attempted. I can't recall for sure but I think it
> behaved
> >> like this at one point, but a lot changed for Erlang 18 and so perhaps
> this
> >> config check got lost along the way.
> >>
> >> --steve
> > _______________________________________________
> > erlang-bugs mailing list
> > erlang-bugs@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-bugs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20151202/03cd5dab/attachment.htm>