Re: Linux Buffer Cache & Mirroring

Jeff V. Merkey (jmerkey@timpanogas.com)
Fri, 05 Nov 1999 10:10:39 -0700

kernel@kvack.org wrote:
>
> On Fri, 5 Nov 1999, Jeff V. Merkey wrote:
>
> > You also need to warn folks that the page used to do this cannot span a
> > page boundry. We use tracking labels to track memory leaks (since the
> > linux kernel does not provide this service) and discovered that the
> > drivers get DMA timeout errors if you allocate two pages (since the
> > tracking header is above the allocation and causes the page start addres
> > to be 16 bytes into the page), then use a buffer heads to span one
> > (which seems broken).
>
> The assumption of buffer_heads having their data aligned to the power of 2
> that the size of the buffer is at is widely present, and why buffers are
> populated with pages (or aligned portions thereof). If you're looking to
> check for memory leaks, there are patches out there that do all the hard
> work for you (memleak-something, I don't remember the url) -- no need to
> reinvent the wheel.

I looked at some of the memory trackers. What I'm using is on par, and
much simpler (it's like the resource tag tracking in Netware).

>
> > Also, I noticed that brw page locks the page in memory. I am not doing
> > this and am not seeing any problems, but should I? I am calling kmallov
> > with GFP_BUFFER. Does this take care of the locking problem for IO?
>
> If you don't lock the page, then you'll run into troubles if someone else
> tries to read the same page, or the system tries to reclaim the memory.
> Of course, such bugs will tend to only show up under high load.

What is the best method for this? I noticed that there is a page *
structure that uses a PG_Locked bit to flag the page structure. My
concern is that most of this stuff uses macros that can change accross
linux versions. Is this method consistent across all the Linux
versions?

Jeff

>
> -ben

-
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/