From owner-freebsd-stable@FreeBSD.ORG Mon May 10 15:12:55 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72DF016A4CE; Mon, 10 May 2004 15:12:55 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3B3043D41; Mon, 10 May 2004 15:12:53 -0700 (PDT) (envelope-from jin_yuan@fastmail.fm) Received: from server3.messagingengine.com (server3.internal [10.202.2.134]) by mail.messagingengine.com (Postfix) with ESMTP id 08D88B43643; Mon, 10 May 2004 18:12:51 -0400 (EDT) Received: by server3.messagingengine.com (Postfix, from userid 99) id 8843F17102C; Mon, 10 May 2004 18:12:52 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.3 (F2.71; T1.001; A1.60; B2.21; Q2.21) From: "Jinyuan Li" To: freebsd-stable@freebsd.org Date: Mon, 10 May 2004 15:12:52 -0700 X-Sasl-Enc: UXlJ34Wur670suevxwLVWA 1084227172 Message-Id: <1084227172.8010.196202591@webmail.messagingengine.com> cc: freebsd-current@freebsd.org Subject: BUG in vm in stable RELENG_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2004 22:12:55 -0000 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