Re: Linux Buffer Cache & Mirroring

Jeff V. Merkey (jmerkey@timpanogas.com)
Fri, 05 Nov 1999 09:29:36 -0700

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).

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?

Jeff

Andrea Arcangeli wrote:
>
> "Jeff V. Merkey" <jmerkey@timpanogas.com> writes:
>
> > One thing you should warn folks about is that they need to call kmalloc
> > with the GFP_BUFFER priority for both the data buffers and the buffer
> > heads so the memory gets mapped logical=physical. Oddly, we did see
>
> There's no difference in the way memory gets mapped.
>
> The only point of GFP_BUFFER is to avoid entering the swapout path
> while doing the allocation. If you enter the FS (in the swapout path)
> while you are just in the FS, you can deadlock (for example in the
> lock_super() stuff). That was happening in the early 2.2.x for example.
>
> > some problems with DMA timeouts if the buffer head was not also alloc'd
> > with GFP_BUFFER priority.
>
> This is a side effect. If you don't use GFP_BUFFER then the allocation
> can be very slow as it may do I/O and even wait for I/O
> completation.
>
> --
> Andrea

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