Re: Scheduling problem - need some help here

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

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.

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.

Other points are:

- vax cpu_need_resched doesn't seem to differentiate between locally
  running lwp and an lwp running on another cpu.

- I can't see how hardclock would result in userret being called, but
  like I said - I don't know vax.


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.

End of ramblings...

Nick