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/
prev parent 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).