[Scheduler] [MMU] KillProcess should clear page table of process

[trylimits]

The scheduler function SchedulerKillProcess(..) should clear the page tables etc., i.e. it should call a MMU function which takes care of a proper cleanup of the allocated memory.

[trylimits]

@mpe5651 I guess you are most suitable for solving this issue in shortest time.

[ghost]

@trylimits I already implemented a function MMUFreeAllPageFramesOfProcess(process_t* process) which clears the L1 page tables of processes. I'll check it by the evening.

[trylimits]

@mpe5651 I've added the code to the Scheduler's function KillProcess and made two minor changes in your code. Unfortunately, I have no idea how we can test if this function works correctly. Could you please define a test case?

Important sidenote: Calling this function is very very slow. In fact it tooks about 5 seconds to free the page tables which seems pretty long to me. The code has actually two nested for-loops which iterate over 4096, respectively 256 (thus 1048576) entries. Can't we improve this code?

[ghost]

I know, I too dislike the duration of freeing a whole process page table. The problem is you never know which page frames the process uses. The test is performed by debugging: you calculate the page frame base address out of a L2 PTE, calculate the page frame number and check od this frame is freed in the bitsmap. I can confirm this is done correctly. The reason why i left this ticket open is the duration. I would suggest an array (preferably dynamic) which contains the page numbers. Then the iterations would become unnecessary. Let us discuss this on wednesday. At the moment i'm very busy with forcing other projects and therefore i need sime time for preparation.

[ghost]

@trylimits page freeing fixed :-) please assure yourself and then close the ticket.

by the way: the duration of the freeing function decreased noticeably

[trylimits]

@mpe5651 I tested the changes and the test case didn't succeed. Test case was as following (debug output ON):

root@fhv-os# hello
[DEBUG @ 3280] Console: Input command received (length=5): hello
[DEBUG @ 3280] Systemcall number=59
[DEBUG @ 3280] message arg=hello
[DEBUG @ 3280] Command=hello and has 0 arguments
[DEBUG @ 3290] Data Abort Interrupt occured
[DEBUG @ 3290] dabt interrupt from pid=1, with fault state=5
root@fhv-os# Hello World!
[DEBUG @ 3310] Scheduler is killing process with pid=1
hello
[DEBUG @ 7280] Console: Input command received (length=5): hello
[DEBUG @ 7280] Systemcall number=59
[DEBUG @ 7280] message arg=hello
[DEBUG @ 7280] Command=hello and has 0 arguments
[DEBUG @ 7290] Data Abort Interrupt occured
[DEBUG @ 7290] dabt interrupt from pid=1, with fault state=5
root@fhv-os# Hello World!
[DEBUG @ 7310] Scheduler is killing process with pid=1
h[DEBUG @ 7810] Data Abort Interrupt occured                           <--- See this line (typed char was 'h')
[DEBUG @ 7810] dabt interrupt from pid=0, with fault state=1
[DEBUG @ 7810] Alignment fault!

It works well if the MMU's work is not interrupted. However, if the user immediately types in a new character while (at least I assume) the MMU is still freeing pages a dabt interrupt occurs for the running process. If my assumption is correct and we are facing problems if we interrupt the MMU's freeing work we should just avoid context switches while a process is beeing killed.

[ghost]

@trylimits is there any logical explanation why we get pabts using this functions when we enable kernel debug messages, but there are no pabts when the debug messages are disabled? have you observed this behavior?

[trylimits]

Could you please re-check the above statement. This behavior sounds pretty strange.

[ghost]

fixed