Date: Fri, 22 Jan 1999 20:25:56 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "John S. Dyson" <dyson@iquest.net> Cc: rcarter@pinyon.org (Russell L. Carter), dufault@hda.com, hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change Message-ID: <199901230425.UAA58213@apollo.backplane.com> References: <199901230415.XAA62055@y.dyson.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Guys, guys... when I said 'priority' I simply meant 'some sort
of scheduling mechanism'. I didn't mean 'priority' in the
sense of some arbitrary static number, nor do I infer that
we intentionally block any processes when memory *is* available.
And when I said 'scheduler' I didn't mean scheduling for cpu,
ok? I meant scheduling who the available memory is given to.
As in deciding intelligently.
There are lots of ways to do this. The easiest is to change
FreeBSD's notion of when to block waiting for memory. Right
now it's notion is ( from vm_page_alloc() ):
case VM_ALLOC_NORMAL:
if (cnt.v_free_count >= cnt.v_free_reserved) {
m = vm_page_select_free(object, pindex, PQ_FREE);
KASSERT(m != NULL, ("vm_page_alloc(NORMAL): missing page
on free queue\n"));
} else {
m = vm_page_select_cache(object, pindex);
...
}
So, for example, one way to schedule memory is to adjust
the notion of cnt.v_free_reserved based on some dynamic entity
associated with the process:
if (cnt.v_free_count >= cnt.v_free_reserved + curproc->fubar) {
And then make curproc->fubar a function of something. That is ALL
I am saying here.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901230425.UAA58213>