linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: linas@austin.ibm.com
To: "Christopher R. Johnson" <cjohnson@gcctech.com>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: General question about caching
Date: Fri, 2 Apr 2004 16:17:06 -0600	[thread overview]
Message-ID: <20040402161706.B58706@forte.austin.ibm.com> (raw)
In-Reply-To: <406DBE90.1060603@gcctech.com>; from cjohnson@gcctech.com on Fri, Apr 02, 2004 at 02:27:12PM -0500


On Fri, Apr 02, 2004 at 02:27:12PM -0500, Christopher R. Johnson wrote:
>
> Ok, I'll give it a shot.
>
> 1. Isn't it taking up memory?  If not then what does "Cached: 11924kB"
> mean in meminfo?  With my embedded application, I desperately need every
> byte I can get; 11924k is HUGE in my little 32MB environment.

Its only using space that no one else is using.  If you malloc more
space for yourself, the cache will shrink; but for the most part the
kernel will try to use all of the memory it can.  No harm in that, it
usually helps.

> 2. Not sure why its vague that avoiding needless caching in ram of stuff
> that's already in ram is silly.  Perhaps the performance hit is minimal,
> but its still silly.  At the very least won't there be some needless
> data copying?

Yes, there's probably some needless copying, although I haven't really
read through the linux kernel ramdisk implementation, so I don't really
know. They might have gotten smart.  But things like buffer heads
contain all sorts of flags and locks and linked lists and
what-not in there, so you can't just poof-and-make it go away.

> Which cache is used for file contents?  That would be the one I don't need.

Not sure what you mean.  The buffer cache?

Maybe you're thinking about the /proc/slabinfo?  It hold the various
allocated and free blocks of various sizes, it speeds up allocation.

Different filesystems organize thier data in different ways; e.g. reiserfs
packs file tails into one block.  There's no trivial way to figure out
what data is where in a file system, which is why the the "users" usually
go through buffers.  You can layer block devices onto files in
arbitrary file systems on block devices ad infinitum; there's no trivial
untangling of this stuff.

--linas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

      reply	other threads:[~2004-04-02 22:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-02 16:20 General question about caching Christopher R. Johnson
2004-04-02 17:02 ` linas
2004-04-02 19:27   ` Christopher R. Johnson
2004-04-02 22:17     ` linas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040402161706.B58706@forte.austin.ibm.com \
    --to=linas@austin.ibm.com \
    --cc=cjohnson@gcctech.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).