[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"caching pager"
From: |
Ognyan Kulev |
Subject: |
"caching pager" |
Date: |
Fri, 15 Aug 2003 11:29:59 +0300 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030714 Debian/1.4-2 |
Hi,
Thinking about ext2fs and ext3fs without 1G limit, an idea came to me.
The purpose of this mail is that to be considered when redesigning
libpager API and/or implementation.
The classic way in which filesystems work in monolithic kernels is using
block cache. This block cache has no fixed size and spans free memory
of system. Each block can be thrown away by the kernel at any given
time if it is not locked.
Let's suppose our pager have 64-bit offsets (like in the Neal's patch an
year and half ago). We can add two basic operations: map and
throw_away. Mapping maps block/page/fragment at _random location_ in
memory. Of course, it only seems random to user thread. The exact
location is decided by the Hurd, glibc, and/or microkernel. When the
Hurd, glibc, and/or microkernel decide that block is good candidate to
be thrown away, throw_away is called. It is important that throw_away
should be able to reject throwing away, for cases like block in use.
There are some details here, but this is the basic idea.
Regards
--
Ognyan Kulev <ogi@{fmi.uni-sofia.bg,fsa-bg.org}>
7D9F 66E6 68B7 A62B 0FCF EB04 80BF 3A8C A252 9782
- "caching pager",
Ognyan Kulev <=