lkml.org 
[lkml]   [1999]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.3.28 more on ramdisk problems....
On 1999-11-15 at 22:04:22, Eleonora Autore wrote:
(Tigran?!?)
> Besides, I am looking at the rd_request() and it looks like a joke:
>
> if (CURRENT->cmd == READ)
> memset(CURRENT->buffer, 0, len);
> else
> set_bit(BH_Protected, &CURRENT->bh->b_state);
>
>
> how can it possibly be so simple - where is the actual io? On the other
> hand, it is the same in 2.2.x and 2.2.12 works fine.

Well, it's easy, the ramdisk driver uses (used) the buffer cache to
store the ramdisk blocks. On a block read, it initializes the bh that
is assigned by a higher level caching routine to zeros (since it's a new
block formerly not used), and on write, it simply marks the bh as
"protected", so it won't get thrown away by any memory pressure.
Further, on reads approaching this area, the buffer cache simply returns
the "cached" data in the bh, which then contains the up-to-date data..

At least, that's how it worked. Once, there was an idea to get rid of
the BH_Protected flag, since using the counters have the same effect (if
in use, noone can dump it), but I don't think that happened yet. On the
other hand, maybe the buffer/page cache changes mistreat some of the
assumed behavior, but I can't test it right now...

> Tigran.
(Eleonora?!?)

Janos

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

\
 
 \ /
  Last update: 2005-03-22 13:55    [from the cache]
©2003-2011 Jasper Spaans