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