elysium-developers

[elysium-developers] Disk block server and block sizes

[Kasper V. L. <ve...@da...>]

I've been looking at the XN code, and it seems that it uses a disk block
size that's equal to the hardware page size (e.g. 4kb). The only problem
with this approach is that it gives us quite a lot of internal
fragmentation, but harddisks are quite cheap anyhow...

The role of the disk block server is then to[1]:

* load harddisk blocks into the buffer cache
* allow mapping cached blocks into application address spaces
* commit cached blocks to the harddisk

The applications will implement their own filesystem(s) on top of this.
We still need to figure out what to do when the buffer cache gets filled
up. 

/Kasper

[1] Please note that this is just the role of the initial - unprotected
- disk block server. Later we'll put restrictions on which cached blocks
can be mapped into application address spaces, but for now it should do
the trick.

-- 
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich

Re: [elysium-developers] Disk block server and block sizes

[Adam L. <ag...@li...>]

On Wed, Mar 01, 2000 at 04:20:06PM +0100, Kasper Verdich Lund wrote:
> We still need to figure out what to do when the buffer cache gets filled
> up.=20

The buffer cache not only fills up, it dynamically resizes. If there is any
free memory the buffer cache should eat it, and as soon as their is any
memory pressure the BC should shrink.

I think (if we allow processes to map the BC) that we possibly must walk
page tables and remove mappings (Ouch!)

If we keep BC linear we could protect it with segmentation (e.g. just shrin=
k the segment and tell processes)

This means more TLB entries. It also means less-then-100% BC. If A real 'go=
od' (that means often accessed) page is at the beginning of the BC, then th=
at page
might have to be copied when BC is shrunk.

Comments?

AGL

--=20
Smoking is one of the leading causes of statistics.

Re: [elysium-developers] Disk block server and block sizes

[Kasper V. L. <ve...@da...>]

Adam Langley wrote:
> The buffer cache not only fills up, it dynamically resizes. If there is any
> free memory the buffer cache should eat it, and as soon as their is any
> memory pressure the BC should shrink.
>
> I think (if we allow processes to map the BC) that we possibly must walk
> page tables and remove mappings (Ouch!)

It should be impossible to map the entire BC - you should only be
allowed to map disk blocks that you can prove you have access  to.

We might consider keeping a reverse page mapping function in the kernel
(should be accessible read-only from user-space). Given a physical page,
p,  the function should return the set of virtual addresses - and
corresponding address spaces - that map p. 

/Kasper 

-- 
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218              | Phone: (+45) 8942 5680
Email:  ve...@da...  | WWW: http://www.daimi.au.dk/~verdich