Messages in this thread | | | Date | Tue, 16 Nov 1999 09:11:54 +0100 | From | Janos Farkas <> | Subject | Re: 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/
| |