> I think schedstate_percpu is probably a better place for any per-CPU data
> than struct cpu_data itself.
OK, just a word "state" sounds a little bit inaccurate :)

> If sched_slept() needs to be called with the sched_mutex held then it may
> need to happen earlier, perhaps in sleepq_enter() - or later, in mi_switch().
At this moment, there is no need to hold sched_mutex at call, but changing it
would be really reasonable. I would vote for moving it to the sleepq_enter().
There is no reason to call it later and mi_switch() we would need additionaly
check l_stat - that costs.

> Is it still worth having a "newl" argument passed to mi_switch()? I think it
> should be removed, and new LWPs to run should always be selected from
> the run queues.
I did not saw, that we are not using it anymore in the tree. If there are no
reason to keep this functionality - then it certainly could be removed.

> I don't like the idea of having two locks per cpu, it complicates things
> somewhat and increases overhead.
You have misunderstood me. I am suggesting only one of those two variants.
Primarily variant B, which looks more flexible, thought.

> One change I have but have made but not checked in is to rename
> sched_lock/unlock to spc_lock/unlock, <...>
Well, sched_* looks much more intelligibly.

> I think both of those should be per-LWP, and the sysctl/libkvm interface
> should mimic the old behaviour by adding the values for all LWPs in a
> process.
As I understand, you would tend to "LWPize" this part, hence, there would be
more data moving from proc to lwp. One should also keep in mind that top(1)
and ps(1) interfaces are defined by POSIX.
Can you elaborate with this?

> Why does p_pctcpu need to be scheduler specific?
Well, I said IN-specific :)

> I'm not sure we should rename the define in sysctl.h.
Well, just did that according to, for example, KERN_SYSVIPC_INFO ->
KERN_OLDSYSVIPC_INFO. I am not sure, we could leave the name.

> If we're adding new sysctl values for schedulers, I think it would make
> sense to denote which scheduler they belong to, however from a Google search
> it looks like FreeBSD just puts the values under "kern.sched". So I think in
> that instance it's better to follow their lead.
You mean, add something like "4bsd" value in this node:
+	sysctl_createv(clog, 0, NULL, NULL,
+		CTLFLAG_PERMANENT,
+		CTLTYPE_NODE, "sched",
+		SYSCTL_DESCR("Scheduler options"),
+		NULL, 0, NULL, 0,
+		CTL_KERN, KERN_SCHED, CTL_EOL);

-- 
Best regards,
Mindaugas
www.NetBSD.org