From owner-freebsd-hackers Fri Jul 30 12:19:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id CB98D1502F for ; Fri, 30 Jul 1999 12:19:16 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id OAA24252; Fri, 30 Jul 1999 14:18:37 -0500 (CDT) Date: Fri, 30 Jul 1999 14:18:37 -0500 From: Alan Cox To: Matthew Dillon Cc: David Greenman , hackers@freebsd.org Subject: Re: patch for behavior changes and madvise MADV_DONTNEED Message-ID: <19990730141837.B22738@cs.rice.edu> References: <199907162234.PAA21850@apollo.backplane.com> <19990720014804.A21777@cs.rice.edu> <199907291856.LAA77471@apollo.backplane.com> <19990730000528.L10860@cs.rice.edu> <199907301651.JAA91354@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <199907301651.JAA91354@apollo.backplane.com>; from Matthew Dillon on Fri, Jul 30, 1999 at 09:51:35AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 30, 1999 at 09:51:35AM -0700, Matthew Dillon wrote: > > I'm not sure I see how MADV_FREE could slow performance down unless, > perhaps, it is the overhead of the system call itself. e.g. if malloc > is calling it on a page-by-page basis and not implementing any hysteresis. > It's the system call overhead. Adding (more) hysteresis would reduce the overhead by some factor, but we'd still be making unnecessary MADV_FREE calls. Calling MADV_FREE accomplishes nothing unless the system is actually short of memory. The right way to address this problem is likely to add a mechanism to the VM system that sends a signal to the process when MADV_FREE would actually be beneficial. > 2% isn't a big deal. MADV_FREE theoretically makes a big impact on > paging performance in a heavily loaded & paging system. If your tests > were run on a system that wasn't paging, you weren't testing the right > thing. > 99% of our user base, whose machines aren't thrashing during a "make world" or other normal operation, shouldn't pay a 2% penalty to produce a theoretical improvement for the 1% that are. At best, that's "optimizing" the infrequent case at the expense of the frequent, not a good trade-off. In any case, the man page for malloc/free explains how to change the default, if you're a part of the "oppressed" 1%. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message