public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Zeng Yu" <yu_zeng@263.net>
To: "Andrea Arcangeli" <andrea@suse.de>
Cc: "Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: Ramdisk Bug?
Date: Thu, 28 Jun 2001 22:21:15 +0800	[thread overview]
Message-ID: <001201c0ffdd$989f35c0$0101a8c0@weqeqe> (raw)
In-Reply-To: <001e01c0ff14$0bdc7540$0101a8c0@weqeqe> <20010627165945.A16936@athlon.random>

> > I think find a ramdisk bug of 2.4.4 kernel -- ramdisk
> > use both buffers and cached mem of the same size, thus
> > double the mem use.
> > mke2fs -m0 /dev/ram1
> > mount /dev/ram1 /mnt
> > dd if=/dev/zero of=/mnt/data bs=1k count=110000
> > cat /proc/meminfo will see that both buffers and
> > cached mem increase about 110M of size. More worse,
> > the cached mem won't be released untile the ramdisk
> > be umounted. I attach the meminfo and slabinfo before
>
> the "more worse" part is the only thing which is wrong. The fact cache
> also grows to 110M is expected and it won't change. With the
> blkdev-pagecache patch the cache will grow to 220M and it will shrink to
> 110M if you are low on memory (buffer cache will only be allocated for
> the superblock and inode metadata with ext2).

broken, clean 2.4.4 kernel with blkdev-pagecache-1 and o_direct-5 patch
mke2fs /dev/ram0; mount /dev/ram0 /mnt
VFS:can't find an ext2 filesystem on dev ramdisk(1,0)
mount:wrong fs type, bad option, bad superblock on /dev/ram0 ...
I miss something?

BTW, I noticed that the blkdev-pagecache had been submitted early in 2.4.5
pre1,
but not included in 2.4.5 final, 2.4.5 still has the bug -- can't release
mem unless
the ramdisk unmounted. Would this be considered not a problem or just a
bearable
side-effect for some elegant designs?

> use ramfs if you want zero ram duplication and you don't care about the
> physical representation on disk of your data in cache.
 ramfs's src code inode.c says it not for general use, so not try and I
can't find any
docs about how to use it.

> Try this patch to fix the "more worst part"  (beware totally untested).
seems works. will do more tests though. thanks!

regard,

Zeng Yu


      reply	other threads:[~2001-06-28 14:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-27 14:18 Ramdisk Bug? Zeng Yu
2001-06-27 14:59 ` Andrea Arcangeli
2001-06-28 14:21   ` Zeng Yu [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='001201c0ffdd$989f35c0$0101a8c0@weqeqe' \
    --to=yu_zeng@263.net \
    --cc=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.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