Memory manager for user side

[Ozguxxx]

Hey all, I need some ideas about my ideas on user side. I am thinking on implementing user process with each having their own address spaces. In that scenario, each will have its own page directory, each process will be linked to same place. My question is: I am kinda confused on memory manager for user processes. While having each user process with its own address space, I need to have one memory linked list for each user process for keeping used and free virtual memory areas. Can there be a simpler solution to this?

[Tim]

No, that's exactly the right solution.

Some kind of tree tends to work better. Looking up an element in a linked list takes O(n), whereas looking up an element in a tree is O(log2 n), where n is the number of items. You want lookups to be fast, since they will happen on each page fault and also each time you access the list/tree to allocate/free memory.

[Ozguxxx]

Hey, thanx for answer, I will go on in that way, but i need some reading. well, another question of mine is... While loading an executable I think it is not necessary to load it into memory consecutively but it is necessary to map its physical addresses into virtual addresses consecutively, is that right? I mean we can load executable program in a fragmented way -fragmented into free pages of physical memory- but for running it appropriately we need to map it in a consecutive way so that in virtual realm cpu does not see fragmentation. I am just suspecting about fragmented instructions between pages I mean one byte of an instruction is in some page and other part of instruction is in another page that may not be in the adjacent page, but consequently cpu sees only virtual addresses, right? I hope Im clear, Thanx.

[Pype.Clicker]

the instruction flow will indeed only see "virtual" addresses. No matter whether a page boundary occurs between two instruction or in the middle of an instruction.

Code: Select all

foreach(4K to load from file) {
   frame=getFreeFrame();
   disk.read(&frame, yourFile, current_offset,4K);
   pages.map(current_virtual_address,frame);
   current_offset+=4K; current_virtual_address+=4K;
}

[Ozguxxx]

Ok, another question, I am thinking of separating kernel and user address spaces, but currently Im shocked by the fact that I will just tell. Well, I might be wrong in design aspect but this is why Im asking here, now. Anyway while allocating memory we want that a physical page should either contain a user code/data or kernel code/data, if this is not the case then there will be protection leak, right? I mean a PHYSICAL page cannot contain both user and kernel data or code, right?
So in fact allocating memory while user side is allocating pages in physical realm, right? I mean physical memory manager cannot still be a simple bitmap. I do not mean granularity is in pages but in fact kernel cannot use a physical (not virtual) page that user uses so as a result we must also create a software protection scheme for physical memory, at least we also must keep track of physical pages, which are user pages and which are kernel pages, in physical memory manager, right? Or is my brain playing some tricks on me to tell me Ive messed up very badly? I cannot currently read any documentation as far as design aspects are concerned ;D, so I can accept rough and rude suggestions that tell me which book, article, etc. to read. Thanx.

[Adek336]

not sure if I understand. This is how I do it:

-alloc4k() finds me a free, physical page
-a. if is used by kernel, the kernel uses the page how it wants to.
-b. if by user, as well.

If I map the page to virtual space, I give it PTE_USER bit set or not whether appropriate. And one page is used only by kernel or only by user, fe. this page is used by the fs caching, this page by OpenOffice (user thread), this one is used by XJEvirus2.11.

Cheers,
Adrian

[Ozguxxx]

Adek336: Do you mean PTE_USER bit in page table entries? Ill try to rephrase everything. Ok, I am talking about physical pages, not virtual pages. We know that even if we separate kernel and user address spaces, they will eventually share the same physical memory. Suppose I allocate some memory in kernel address space and then I switch to a user task, and it also allocates some memory, now suppose that these memories are by chance mapped onto same PHYSICAL page -I do not mean that they are mapped onto same physical address but assume that they are in same physical page- so that kernel and user shares same physical memory. Since user has access to this new memory, it has access to all of this page, which also includes some kernel memory. So it can mess this kernel memory by some evil action, which is a kind of protection lack. Am I correct up to this point or am i making a basic mistake?
I think making a kind of list for physical memory so that users and kernel never share same physical page will solve that problem but then this means more memory for memory management, and some kind of egg, chicken scenario...
Giving users some predetermined size of memory will also solve this problem but this is not a very good idea because you know you can test windows with a program that creates intentional memory leak until windows says that it is short in virtual memory so this is not a good solution. I mean we must be able to give user any amount of memory that actual physical system can theoretically handle.
Any ideas about this? thanx. I hope I am clearer.

[Adek336]

Suppose I allocate some memory in kernel address space and then I switch to a user task, and it also allocates some memory, now suppose that these memories are by chance mapped onto same PHYSICAL page -I do not mean that they are mapped onto same physical address but assume that they are in same physical page- so that kernel and user shares same physical memory

Ah, I see. You mean that in your design one physical page can be shared between kernel and a user thread?

Well, I actually never faced this as if I allocate a page, it is either for the kernel or for user. If I want to pass some data from kernel to user, I just copy it to it's mem space, to a new physical page.

are by chance mapped onto same PHYSICAL page -I do not mean that they are mapped onto same physical address

not sure about this. I would alloc4k() for each need and not reuse pages which are partially used. Do you manage the user heap from the kernel by any chance?

Cheers,Adrian

[Ozgunh]

Well, ok, Ive just figured out that I can also solve the problem from virtual mm. I was making some basic mistake, in fact kernel and user cannot by any chance share physical pages after loading user program into memory safely, since their address spaces are sperated. Thanx...