Re: Scheduling problem - need some help here

[Anders Magnusson <ragge%tethuvudet.se@localhost>]

Hi,

Den 2020-07-28 kl. 13:28, skrev Nick Hudson:
> On 28/06/2020 16:11, Anders Magnusson wrote:
> > Hi,
> >
> > there is a problem (on vax) that I do not really understand. Greg Oster
> > filed a PR on it (#55415).
> >
> > A while ago ad@ removed the  "(ci)->ci_want_resched = 1;" from
> > cpu_need_resched() in vax/include/cpu.h.
> > And as I read the code (in kern_runq.c) it shouldn't be needed,
> > ci_want_resched should be set already when the macro cpu_need_resched()
> > is invoked.
> >
> > But; without setting cpu_need_resched=1 the vax performs really bad (as
> > described in the PR).
> >
> > cpu_need_resched may have multiple values nowadays, setting it to 1 will
> > effectively clear out other flags, which is probably what makes it work.
> >
> > Anyone know what os going on here (and can explain it to me)?
>
> I'm no expert here, but I think the expectation is that each platform
> has its own method to signal "ast pending" and eventually call userret
> (and preempt) when it's set - see setsoftast/aston.
VAX has hardware ASTs, (AST is actually a VAX operation), which works so 
that if an AST is requested, then next time an REI to userspace is 
executed it will get an AST trap instead and then reschedule.
> As I don't understand vax I don't know what
>
>     197 #define cpu_signotify(l)     mtpr(AST_OK,PR_ASTLVL)
>
> is expected to do, but somehow it should result in userret() being 
> called.
Yep, this is the way an AST is posted. Next time an REI is executed it 
will trap to the AST subroutine.
> Other points are:
>
> - vax cpu_need_resched doesn't seem to differentiate between locally
>   running lwp and an lwp running on another cpu.
Most likely.  It was 20 years since I wrote the MP code (and probably 
the same since anyone tested it last time) and at that time LWPs didn't 
exist in NetBSD.  I would be surprised if it still worked :-)
> - I can't see how hardclock would result in userret being called, but
>   like I said - I don't know vax.
When it returns from hardclock (via REI) it directly traps to the AST 
handler instead if an AST is posted.
> http://src.illumos.org/source/xref/netbsd-src/sys/arch/vax/vax/intvec.S#311 
>
>
> I believe ci_want_resched is an MI variable for the scheduler which is
> why its use in vax cpu_need_resched got removed.
It shouldn't be needed, but obviously something breaks if it isn't added.

What I think may have happened is that someone may have optimized 
something in the MI code that expects a different behaviour than the VAX 
hardware ASTs have.  AFAIK VAX is (almost) the only port that have 
hardware ASTs.

Thanks for at least looking at this.

-- Ragge