Date: Mon, 10 May 2004 15:12:52 -0700 From: "Jinyuan Li" <jin_yuan@fastmail.fm> To: freebsd-stable@freebsd.org Cc: freebsd-current@freebsd.org Subject: BUG in vm in stable RELENG_4 Message-ID: <1084227172.8010.196202591@webmail.messagingengine.com>
next in thread | raw e-mail | index | archive | help
Hi, guys,
I would like to collect your response before submitting a bug report.
Any comment would be greatly appreciated.
The bug is in the following piece at vm/vm_object.c:
/*
* Try to optimize the next page. If we can't we pick up
* our (random) scan where we left off.
*/
if (msync_flush_flags & MSYNC_FLUSH_SOFTSEQ) {
if ((p = vm_page_lookup(object, pi + n)) != NULL)
goto again;
}
The piece of code tries to optimize locating next vm_page. When it does
so, kernel always flushes the vm_page p in an ascending order (in term
of p->pindex). However, the problem comes in when one round finishes
(when vm_page_lookup returns NULL), the kernel will then begin with
vm_page np and redo most of the whole work again!!!
If beforehand, all vm_pages are in an ascending order, the total cost
would be n^2/2 instead of n. We could fix the code by break the loop
when vm_page_lookup returns NULL. However, since the vm_pages are not
always sorted, we might solve this problem only by disabling
MSYNC_FLUSH_SOFTSEQ flag:
99c99
< static int msync_flush_flags = MSYNC_FLUSH_HARDSEQ |
MSYNC_FLUSH_SOFTSEQ;
---
> static int msync_flush_flags = MSYNC_FLUSH_HARDSEQ;
Notice this bug doesn't violate any correctness of the kernel, though it
causes so much unnesscary disk traffic.
Bests
Jinyuan
--
http://www.fastmail.fm - Send your email first class
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1084227172.8010.196202591>