Any ideas on why this page fault might be coming from? I would attach the code but code is not very readible and very long now so what can the error be? I am almost sure that no problem with memory manager and I am sure that there must be no page fault. I have been trying to fix this crab for two days >:( anyway, thanx...stack problem
-
Ozguxxx
stack problem
Hi everybody, process manager I am trying to finish seems to run any number of threads when stack size of threads are small like when stack size is 2K then 100 threads can run but when I try to make stack size 5k then I get a meaningless page fault??? Anyway you say:" Lower stack size", but this time scheduler, being a recursive function, needs big stack and since it runs in context of any of threads, I cannot lower stack size of threads so I am in a bad situation. Any ideas on why this page fault might be coming from? I would attach the code but code is not very readible and very long now so what can the error be? I am almost sure that no problem with memory manager and I am sure that there must be no page fault. I have been trying to fix this crab for two days >:( anyway, thanx...
Any ideas on why this page fault might be coming from? I would attach the code but code is not very readible and very long now so what can the error be? I am almost sure that no problem with memory manager and I am sure that there must be no page fault. I have been trying to fix this crab for two days >:( anyway, thanx...-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:stack problem
how are your stacks set up ? do you fill properly all their pages with phyiscal memory ?
btw, having a recursive scheduler might not be a good idea, especially if its recursion depth may depend on the amount of threads in the system (therefore having too much threads might lead to a stack overflow in the kernel ... bleech)
btw, having a recursive scheduler might not be a good idea, especially if its recursion depth may depend on the amount of threads in the system (therefore having too much threads might lead to a stack overflow in the kernel ... bleech)
-
Ozguxxx
Re:stack problem
Currently I am working in first 4 MByte and it is initially mapped onto itself so I am sure that stacks are mapped to some physical memory, but thanx I think I am going to check it again maybe there is some mistake there...
-
The Pro from Dover
Re:stack problem
Very likely, especially if you are in a graphics mode at the time.
Even if you aren't, it very likely will present problems, in that the video memory is not in the system main memory itself, but part of the video adapter - the memory addressing hardware automatically remaps that section of the memory to the video memory buffers, even when not in use as such, IIRC. If nothing else, accessing it will be a great deal slower than accessing ordinary memory, even though video memory is often much faster. Not only does it have to go through the PCI bus rather than the local bus (even on motherboards with built-in video), but you generally have to wait for the GPU and the video refresh to relinguish control of the memory. According to Graphics Programmer's Black Book (chapter 4, 'The Display Adapter Cycle Eater'), because of the video card refreshes the screen images, the CPU can only access the video memory one cycle out of every 10 (for SVGA video cards circa 1995; I don't know how it may have changed with the inroduction of high-performance 3D accelerator cards, but given the demands of displaying 1600x1200, and the complexity of modern graphics processors, I would expect it would be, if anything, even worse). While it won't smash ycode or data stored there, it will surely run much slower than it would otherwise.
BTW, the way you wrote that gives me the impression that you have your stacks set to grow up into memory rather than down, is that correct? If so, keep in mind that this will play merry hell with al lot of compiled code, as code to access the stack frames depends on the direction of the stack, and every compiler I know of assumes it grows downwards.
Even if you aren't, it very likely will present problems, in that the video memory is not in the system main memory itself, but part of the video adapter - the memory addressing hardware automatically remaps that section of the memory to the video memory buffers, even when not in use as such, IIRC. If nothing else, accessing it will be a great deal slower than accessing ordinary memory, even though video memory is often much faster. Not only does it have to go through the PCI bus rather than the local bus (even on motherboards with built-in video), but you generally have to wait for the GPU and the video refresh to relinguish control of the memory. According to Graphics Programmer's Black Book (chapter 4, 'The Display Adapter Cycle Eater'), because of the video card refreshes the screen images, the CPU can only access the video memory one cycle out of every 10 (for SVGA video cards circa 1995; I don't know how it may have changed with the inroduction of high-performance 3D accelerator cards, but given the demands of displaying 1600x1200, and the complexity of modern graphics processors, I would expect it would be, if anything, even worse). While it won't smash ycode or data stored there, it will surely run much slower than it would otherwise.
BTW, the way you wrote that gives me the impression that you have your stacks set to grow up into memory rather than down, is that correct? If so, keep in mind that this will play merry hell with al lot of compiled code, as code to access the stack frames depends on the direction of the stack, and every compiler I know of assumes it grows downwards.
-
Ozguxxx
Re:stack problem
Well thanx for explanation, I had no info about graphic adapters, now I have have some. 
I think problem was caused by my overwriting this video memory at 0xa0000. Because when I overwrite about over 655K in main memory, computers starts doing very unpredictable things and when I started to work above 1 Meg problem is fixed, now I can increase stack of each thread up to 50K and no problem is existent. Well some page faults are still causing problems but they are irrelevant. Anyway if you are struggling to write your own bootloader I advise you to do all your work over 1 Meg becuase below 1 Meg is full of data that you should not touch coming from 8086 times... I think this is why grub does not let you to load your kernel below 1 Meg. BTW I cannot understand your point in upward growing stacks, can that be possible I mean upward growing stacks? Thanx for help...
I think problem was caused by my overwriting this video memory at 0xa0000. Because when I overwrite about over 655K in main memory, computers starts doing very unpredictable things and when I started to work above 1 Meg problem is fixed, now I can increase stack of each thread up to 50K and no problem is existent. Well some page faults are still causing problems but they are irrelevant. Anyway if you are struggling to write your own bootloader I advise you to do all your work over 1 Meg becuase below 1 Meg is full of data that you should not touch coming from 8086 times... I think this is why grub does not let you to load your kernel below 1 Meg. BTW I cannot understand your point in upward growing stacks, can that be possible I mean upward growing stacks? Thanx for help...