From owner-freebsd-current Mon Mar 6 10:54:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA14443 for current-outgoing; Mon, 6 Mar 1995 10:54:12 -0800 Received: from Root.COM (implode.Root.COM [198.145.90.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id KAA14415 for ; Mon, 6 Mar 1995 10:54:03 -0800 Received: from corbin.Root.COM (corbin.Root.COM [198.145.90.18]) by Root.COM (8.6.8/8.6.5) with ESMTP id KAA03418; Mon, 6 Mar 1995 10:53:42 -0800 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.9/8.6.5) with SMTP id KAA02254; Mon, 6 Mar 1995 10:53:41 -0800 Message-Id: <199503061853.KAA02254@corbin.Root.COM> X-Authentication-Warning: corbin.Root.COM: Host localhost didn't use HELO protocol To: terry@cs.weber.edu (Terry Lambert) cc: current@FreeBSD.org Subject: Re: more ETXTBSY bugs In-reply-to: Your message of "Mon, 06 Mar 95 11:30:03 MST." <9503061830.AA18781@cs.weber.edu> From: David Greenman Reply-To: davidg@Root.COM Date: Mon, 06 Mar 1995 10:53:41 -0800 Sender: current-owner@FreeBSD.org Precedence: bulk >> >All this may be old behaviour. There is certainly some new behaviour: >> >The ETXTBUSY bit didn't go away while I was running `make' in the >> >background for 10-20 minutes. Perhaps the vnode and associated buffers >> >didn't go away either, and clog up the caches. >> >> There are a lot more cached objects than before (several thousand on a >> machine with a lot of memory). You'd have to access several thousand >> previously unaccessed files before you'd flush out the one that is VTEXT. > >There is an intentionally restrictive buffer cache limit of 10% of >available memory in some modern systems because of this problem. Is >this a good or a bad idea? It's never a good idea to not use free memory for file caching. Using memory for file caching that is currently being used to cache VM pages may not be such a good idea. We've tried several different approaches - the current scheme is escentially to not disturb pages that have faulted in and only use memory that would otherwise be free. This sets the upper limit. The lower limit comes from the fact that pages are always allocated when needed for buffers (even if these pages have to come from a process's VM); thus the total number of buffers sets a lower limit on how small the cache can shrink. This number is currently about 5% of memory, and we our currently considering increasing this to 10%. >A lot of what is "common knowledge about VM" is no longer applicable >with a unified cache, so this limit might not be as good an idea as >it seems to be. The algorithms are difficult to get right. John has been advocating that pages involved in file I/O should compete with traditional VM pages. I've seen reduced performance when doing this in some cases and haven't seen any proof of increased performance..so I'm unconvinced. -DG