Messages in this thread | | | Subject | Re: linux mm hack | Date | Mon, 24 Nov 1997 15:16:06 -0500 | From | Benjamin Saller Bender <> |
| |
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.
| |