Re: [patch] ramdisk blocksize

Bradley D. LaRonde (brad@ltc.com)
Fri, 20 Aug 1999 15:15:39 -0400


> >1. Is the page cache just to improve latency, or does it server another
> >purpose or purposes?
>
> Hmm what do you mean exactly? I guess you don't want as reply like "the
> page cache is there to avoid you having to read from disk every time" ;).

I think you answered it below when you said "... the page cache is necessary
for mmaps."

> >2. Is it necessary (or good) for ramdisk access to go through the page
> >cache, or would it be better to "turn it off" somehow for the ramdisk?
>
> It's necessary in 2.3.x because now writes goes into the page cache.
>
> >3. Do you know if the page cache is positioned to replace the buffer
cache
> >eventually?
>
> No, the only object of the page cache is to have file data into it. Also
> the page cache is necessary for mmaps, that's why the page cache is
> at least PAGE_SIZE wide and not blocksize wide.

What is the relationship between the page cache and the buffer cache? Are
they completely separate allocations of memory? Is the page cache stored in
the buffer cache? IOW, is the buffer cache the "back end" for the page
cache? Please excuse my ignorance.

> >The specific symptoms of the ramdisk problem: The filesystem is
recognized,
> >mounts properly, directory reads are OK, but file reads return bogus
data.
> >When using ramdisk as root, the kernel fails with "Kernel panic: No init
>
> It's because we read and write the image using the blockdevice access.

"We" meaning the initrd code?

> So
> we read from buffers and we write to buffers.
> But then in the pagecache
> code we don't read from the ramdisk protected buffers since
> block_read_full_page() create the new buffers from the empty page cache.

This makes me wonder... and I hate to even ask, but I will anyway: :)

Is the ramdisk actually cached? I mean, its primary storage is in (buffer
cache) buffers, but will it actually get copied to the page cache, so that
now there are two copies of (at least some of) the ramdisk data in memory?

> I'll work on this now...

Thank you.

Regards,
Brad

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/