From owner-freebsd-hackers Wed Mar 14 10: 5:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 3DBD437B718 for ; Wed, 14 Mar 2001 10:05:40 -0800 (PST) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f2EI5WJ19838; Wed, 14 Mar 2001 10:05:32 -0800 (PST) (envelope-from dillon) Date: Wed, 14 Mar 2001 10:05:32 -0800 (PST) From: Matt Dillon Message-Id: <200103141805.f2EI5WJ19838@earth.backplane.com> To: Paolo Losi Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: systat -vmstat or iostat IO help References: <3AAF76EB.42D070F9@lombardiacom.it> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : It will use all available memory for disk caching if possible, but it : only caches things you've accessed at least once so I would say you : simply haven't accessed more then 650MB or so worth of file data. : :Is it correct to say that cached file data (file content) :is taken into account in Active/Inactive/Cached page counters if and only if :accessed through the mmap interface? What does it happen when a process :access file data through the filesystem interface (open/read/close)? It doesn't matter how the data is accessed... either through read/write or mmap, it will be cached the same in the system. FreeBSD does have a sequential detection heuristic and will attempt to throw away data earlier that it believes will not be accessed again soon, but the heuristic is implemented both for the VM system (mmap) and for read/write so there actually isn't much of a distinction between the two. :Is it correct to say that in this case the Buffer counter gives you :the detail on how much file data is cached? :This should be how the old 4.4BSD works.... FreeBSD has what is known as a 'unified buffer cache', as you note below. This means that the data mapped by the buffer cache is in fact the same data in the VM page queues, without any duplication. The buffer cache can be thought of as a 'quick lookup' mechanism, making it easier for the kernel to manipulate file data and also holding file block -> disk block translations for the I/O subsystem. If a data buffer is not in the buffer cache it may still be in the VM page queues. The buffer cache is typically limited to a few dozen megabytes worth of mappings. The VM page queues are not limited in any way. So even though the buffer counter might indicate that, say, 20MB of data is in the buffer cache, you could still really have hundreds of megabytes of cached file data in the VM page queues. The buffer counter does not really represent anything. :I know that the buffer cache management has been merged with :the paging system in FreeBSD but I do not know if the above :statements still hold true. : : Thanks : Paolo : :P.S. Matt, your mentoring job is invaluable :) Heh. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message