[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: file access library



On Fri, 18 Sep 1998, Christian Reiniger wrote:
>Dan Kegel wrote:
>
>
>I mainly said the "no mmapping" thing above because I wanted to concentrate
>on the library-level caching system. 
>
>I don't mind having mmapping support in the basic file access code - that's
>a good thing if made properly and if presented as an option. But I also
>like the library-level caching system because it allows for (1)
>guaranteeing the caching of data and (2) caching-after-decoding, i.e.
>making it possible to store data in a compressed form on the disk without
>slowing things down significantly.
I sent a mail about this, but I didn't see it arrive on the list so it might
have been swallowed (raka's three year long email saga is still not
over.  Can anyone tell me what the OUTBOX folder is exactly an how
one uses it?). 

OK cache-after-decode sounds cool, but for other purposes library level
caching is stupid.  OK so we are worried about the kernel dropping a
mmapped page out of the cache.  The kernel will do that  if it has
better things to do with that memory.  So we try to solve this "problem"
by explicitly reading the data into a user level cache.  User level
cache is memory, now what happens if the kernel decides it has
better things to do with that memory?  It swaps it out.  This is _at_ least
as bad the previous situation.

Cache-after-decode is nice, I suggest we do a little design work first
and see how far the idea can be applied.


>>I'll try to read up on Linux memory management.  I recall that
>>this is a big topic for rewriting in the 2.3 kernel... perhaps
>>we should pay attention to that discussion, and mention
>>our requirements... if 2.0 or 2.2 don't have good enough
>>memory management to make this mmap scheme practical, perhaps
>>we can influence 2.3.
Definately.  I always thought linux had good MM, but we might want to be
sure.
>