Re: IOCache vs. block cache
Ingo Weinhold <[email protected]> Fri, 18 Jun 2010 16:30:15 +0200
| Newsgroups | gmane.os.openbeos.kernel.devel |
|---|---|
| Message-ID | <[email protected]> |
On 2010-06-18 at 10:14:11 [+0200], Axel D=F6rfler <[email protected]> = wrote: > Ingo Weinhold <[email protected]> wrote: > > I think eventually the block cache should be rewritten to be VMCache > > based > > with on-demand mapping of hot blocks, but for the time being a simpler > > solution would be possible: > = > Since there is no pressure to release within the next weeks, why not > take the time to start working on the real solution instead of wasting > time with another work-around? > Tackling the real thing would be much more rewarding, at least :-) I'm not motivated to work on that ATM. Besides, for CDs it already works th= at = way (without IOSchedulerSimple and block cache limitation, though). > [...] > > * The block cache would no longer exert any memory pressure. > = > Not entirely true; all blocks that are in-use, dirty or have ongoing > transactions would still require extra memory. While that is not that > much in comparison, it may still create noticeable memory pressure. Yeah, but that is unavoidable, at least where uncommitted transactions are = concerned. > > The only disadvantage I see is the double caching for file content: > > The > > IOCache caches at device level, the file caches at file level. > = > While that is certainly "dumb", I don't think it will be that bad in > the end, since using memory for caching unbalanced probably hurts the > performance more, than only using half of the memory (depending on what > you do). > = > Another small disadvantage would be that the system needs to do much > more to resurrect the blocks from the IOCache than simply return them > from memory. Although this probably doesn't hurt much with the limited > unused blocks list. That's what I think, too. Hot blocks should remain in the unused list. = Reloading others from the IOCache is a bit more expensive -- basically some = overhead for the IORequest creation and processing plus copying the data fr= om = physical memory -- but that shouldn't be too bad either. CU, Ingo ---------------------------------------------------------------------------= --- ThinkGeek and WIRED's GeekDad team up for the Ultimate = GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the = lucky parental unit. See the prize list and enter to win: = http://p.sf.net/sfu/thinkgeek-promo