Cleaning out a process

[pcmattman]

Hi everyone,

I'm having some issues at the moment with how my kernel handles dead tasks. At the moment I use reference counting on every physical page of memory, which works around 80% of the time. However, it still seems to free things that it shouldn't and not free things it should.

So I'm interested as to how you guys actually go about cleaning out a process address space when it finishes running. The biggest problem I have is I never know how many processes might be using a page of memory, so if it gets freed all sorts of trouble can come out - which I see happen every single time I test.

Is reference counting a viable way of doing this? Or is there a better way? By the way, I do this by traversing the entire page directory and all its tables, and checking the reference count on each page I encounter. If it's zero, I free it. If not, I don't.

Thanks in advance.

[Colonel Kernel]

The idea of reference counting is that when you "free" a page, you just decrement its refcount, but don't actually free it unless the refcount reaches 0. I don't think you'd need to scan all the page tables in such a system.

There's a good explanation of how the NT kernel does it in Windows Internals.

[DeletedAccount]

Hi ,
just supplementing Kernel Colonels post . The CRK provided by Microsoft provides a good summary of the book .You may use it along with the book for better understanding .
See : http://www.academicresourcecenter.net/c ... px?ID=6191

Regards
Sandeep

[pcmattman]

The idea of reference counting is that when you "free" a page, you just decrement its refcount, but don't actually free it unless the refcount reaches 0.

Yes, that's what I do.

I don't think you'd need to scan all the page tables in such a system.

The problem is I need to clean things out of the process (stacks, the heap, etc...) that are of arbitrary size.

I guess I could just store a memory map (for want of a better term) that stores information about where the thread heap is, where the stacks are, where the binary is loaded (ie, the actual binary in RAM) and then go through that instead of guessing.

That way I wouldn't need to traverse page directories other than to release page tables.

[Combuster]

In my case, I would do the cleanup just that way - by traversing the page directory structure. You will need to unmap anything you encounter, and everything's practically in there. Just postorder traversal freeing all pages then the PTs and finally the PD. And since its pretty much undefined in my case where stuff has been thrown to due to userland memory management you don't need to do track everything and essentially do the bookkeeping twice.

Basically KISS.
$.02

[pcmattman]

Combuster, the problem with that approach is that I typically end up unmapping pages that were not allocated with the page allocator (for instance, the 4KB -> 1MB region), hence the need for refcounting. If you have any suggestions as to how to avoid this though, I'd be more than happy to consider them.

Also, I'm not entirely sure whether my bookkeeping will even work, but I believe for a start it'll allow me to remove my 2 MB refcount static array (which'll be nice for RAM usage) and possibly improve stability.

[pcmattman]

I've tried keeping track of memory using my own tracking methods, which basically involves building a dynamic memory map for each executing process and when they crash or terminate normally cleaning up based on that map. So far it seems to work nicely (in emulators) and reduces the memory usage for the kernel from around 4 MB to only around 1.5 MB. Which isn't bad, if you ask me.