--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 16, 2007 at 08:29:10AM +0000, Andrew Doran wrote:
> Cool stuff. I have some comments on on the diff if you're interested.
>=20
> - kinfo_proc2 is a intended to be 'highly compatible', so we shouldn't
>   change the size of it.
>=20
> - Changing the size of struct proc isn't as big of a problem, but it
>   shouldn't change because of a kernel option (consider LKMs). It would be
>   good to be able to use the 'specificdata' system for processes, but it
>   doesn't look like that's suitable for use from interrupt context just
>   yet. Perhaps allocate some memory per process using pools, or have a
>   fixed size block in struct proc?

Ok, I see. I'll think about this in some more detail.

> - Is there a reason for the run queues to be tied in with the scheduler
>   implementation?

Yes, there is. Different scheduler implementations may want to use
a rather different runqueue structure. As an example, think of
Mindaugas' Linux-like scheduler.
=20
> - To my mind sched_add() and rem() aren't very descriptive names. How
>   about sched_enqueue() and sched_dequeue()?

I agree. sched_enqueue/dequeue is more descriptive. I'll change that.

> > 1. What to do about priority range? It is currently fixed to
> >    0..127. Different scheduler implementations may want to use a
> >    different priority range. But I'm not sure if allowing a variable
> >    priority range is really sane. All other systems have a fixed range
> >    (FreeBSD has 255, Solaris has 169, Linux has 139), IIRC.
> >=20
> >    Personally, I'd vote to increase MAXPRI at least to 159, which
> >    should be fairly enough for any scheduler.
>=20
> I'm stating the obvious, but I think the main considerations are keeping
> traversal of the queues cheap, while still providing decent
> granularity.

In the mean-time, I have a version of the 4BSD scheduler here with 128
runqueues. Unfortunately, this has quite a negative impact on
performance and interactivity and will need some optimisation to be
really useful.

Regards,
Daniel

--=20
Daniel Sieger
Faculty of Technology
Bielefeld University
wwwhomes.uni-bielefeld.de/dsieger

--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)

iD8DBQFFrL3VJUKmeYzbnToRAtF5AKC7YXWhTX1d6pJ/XEL5qlArQKk3wACgqvBb
PQAOIGVoQT7ntug13XVxJ+4=
=uXlB
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--