Re[2]: How does disk caching work?

From: Q?=Igor ShmuklerQ=20?= (shmukler_at_mail.ru)
Date: 04/17/04

  • Next message: Jim C. Nasby: "Re: How does disk caching work?"
    To: Q?=Jim C.NasbyQ=20?= <jim@nasby.net>
    Date: Sat, 17 Apr 2004 02:19:53 +0400
    
    

    > > > Is there a document anywhere that describes in detail how FreeBSD
    > > > handles disk caching? I've read Matt Dillon's description of the VM
    > > > system, but it deals mostly with programs, other than vague statements
    > > > such as 'FreeBSD uses all available memory for disk caching'.
    > >
    > > Well, the statement is not vague. FreeBSD has a unified buffer cache. This means that ALL AVAILABLE
    > > MEMORY IS A BUFFER CACHE for all device IO.
    > >
    > > > I think I know how caching memory mapped IO works for the most part,
    > > > since it should be treated just like program data, but what about files
    > > > that aren't memory mapped? What impact is there as pages move from
    > > > active to inactive to cache to free? What role do wired and buffer pages
    > > > play?
    > >
    > > If file is not memory mapped it is not in memory, is it? Where do you cache it? Maybe I am missing
    > > somewhing? Do you maybe want to know about node caching?
    >
    > What if the file isn't memory mapped? You can access a file without
    > mapping it into memory, right?

    Read/write/execute require mmap as far as I know. What type of access do you want to perform without the mmap?

    Not that you asked, but I strongly suggest reading AST's book than Design of 44BSD.

    > > When pages are rotated from active to inactive and then to cache buckets they is still retains vnode
    > > references. Once it is in free queue, there is no way to put it back to cache. Association is lost.
    > >
    > > Wired pages are to pin memory. So that we do not get situation when fault handling code is paged out.
    > >
    > > I am not FreeBSD guru so I never heard of BUFFER pages. Is there such a concept?
    >
    > I'm reffering to the 'Buf' column at the top of top. I remember reading
    > something about that being used to cache file descriptors before the
    > files are mapped into memory, but I'm not very clear on what is actually
    > happening.

    Ok, I thought that there was an unknown concept of buffer pages. :)
    _______________________________________________
    freebsd-performance@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-performance
    To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"


  • Next message: Jim C. Nasby: "Re: How does disk caching work?"

    Relevant Pages

    • Re: How does disk caching work?
      ... > Is there a document anywhere that describes in detail how FreeBSD ... > such as 'FreeBSD uses all available memory for disk caching'. ... MEMORY IS A BUFFER CACHE for all device IO. ...
      (freebsd-performance)
    • Re: Cached memory never gets released
      ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
      (Linux-Kernel)
    • Re: Problem: Creating a raw binary string
      ... > While its true that a 64-bit cpu will move twice the data per instruction it ... > Memory bus width plays an important role here and unless it too is widened / ... You are forgetting the two levels of cache in the processor. ... The memory chips are addressed in Row col fashion. ...
      (alt.comp.lang.borland-delphi)
    • Re: Is Greenspun enough?
      ... Most OSes memory map executables directly from the file system so code doesn't pollute the file cache or swap space. ...
      (comp.lang.lisp)
    • Re: Superstitious learning in Computer Architecture
      ... Without a LOT of logic or some other better approach, re-executing the instructions requires re-decoding and it ties up the cache memory bus transferring more data as instructions than the instructions are working on. ... The concept of cache is fundamentally flawed in that it STILL restricts access to one word per clock cycle, when a single modern ALU can easily use 5 plus whatever is eaten up with instruction accesses. ... The size of an optimizing compiler is proportional to the SQUARE of the size of the language times the SQUARE of the complexity of the machine - because all interactions must be considered. ...
      (comp.arch.arithmetic)