lkml.org 
[lkml]   [1997]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: linux mm hack
Date
From
Rik van Riel <mailto:H.H.vanRiel@fys.ruu.nl> writes:
>On Mon, 24 Nov 1997, Benjamin Saller Bender wrote:
>
>> If your looking for some thing to hack under the mm, make address
>> spaces live outside the scope of a process, where a processess is just t
hreads
>> running in an established address space. This would make a number of thi
ngs
>> more elegant IMHO.
>
>Hmm, you mean something like in Digital Unix. There you have
>2 types of items: processes and threads...
>This basically would mean that we have 2 (slim) task[] array's,
>one for the address-space-units and one for the executable units.

Thats the basic idea, however there are a few more things that I would
consider non-obvious. When address spaces have a life of there own you can do
reasonably cool things, even with out the ability to attach threads to address
spaces. If you allow for a shortest path recursive mappings of address spaces
you can implement things like libs by mapping the resident portion of
say libc, sitting in its own address space into another address space,
possiably containing context of execution(threads). A reasonably simple shared
lib impl. Shared memory and other such IPC games can be played along the same
lines.

Persistance can come from such a model quite easily, lock any
executional context in an adress space and check point the AS to disk using a
model very much like swap.
My making AS' first class kernel objects things like DSM become far
more accessable as a distinct set of logical address on one machine can be
addressed by another, etc.

But I ramble...


>- a more efficient kswapd, possibly by using a true inactive list
> (shouldn't be too difficult) We just need to add two items to
> page_struct and a Page_Inactive flag to the flags...
> And also we need a pointer to the task_struct & mm_struct the
> page belongs to, if it's a program page that is...
> (COMMENTS WANTED, IS THIS ENOUGH FOR EFFICIENT OPERATION??)

I could be way off, as I don't know the internals of Linux's swap
system, but I picture something like this. Use a priority coloring scheme to mark
pages, this in helps with the multi-page in/out because pages of the same
color share a temporal locality of access and can be manipulated at the same
time to help with logical pre-fetching. Also when tight memory conditions are
reached you can set the swappable color level to one lower than it was until
things calm down?


> If we have this, vhand only needs to:
> - make sure there are enough truly inactive pages on the
> inactive list (scan every second?) and removing the
> referenced pages from the inactive list

>- pageable pagetables (anyone willing to implement this, it
> seems to be high on the wishlist, but I don't feel like
> implementing this one :( )
Linus' page table design is very good, but where 64 bit address spaces
are sparcity is still a problem. This being the case even paging 64 bits of
address space is a problem. I talked to Linus about guared page tables once,
but he wasn't really all that interested. Pragmatically linux doesn't suffer
from not paging the pagetables...



>
>Although your idea is very neat/clean/beautiful, it won't
>give a performance increase and therefore isn't very high
>on my list of priorities...

Glad you liked it, but really the ideas are not all mine, look at L4,
Mungi and Grasshopper...

>However, if someone else is going to implement it, I'm
>always willing to help in any way I can.
>
>Rik.
>
>----------
>Send Linux memory-management wishes to me: I'm currently looking
>for something to hack...
>

--
Benjamin Saller Bender <case@AppliedTheory.com>
AppliedTheory Communications Software Engineering Group
http://AppliedTheory.com/ Sentio aliquos togatos contra me conspirare.





\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.063 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site