Re: Ongoing 2.4 VM suckage

Anders Peter Fugmann
2001-08-03T16:24:40Z

I dont know task states are defined, but by 'running' I mean that it is
not stopped by the VM, when the VM needs to fetch memory for the
process. What I meant was that if we could somehow garrentee that a
process runs at least for one time-quantum, the system would not grind
to a halt but just feel slow since resheduling occur less often (due to
waiting ie. for memory to be swapped in).

Is there a way to know if a running task needs something that has been
swapped out, if so we could flag the process and not schedule it out
right away:

Flag the current process, it the VM kicks in, and only resched if the
flag is clear, othervice the scheduler just clear the flag.

Still I'm not quite sure what the reason for problem is. Could somone
please summerize it for me. Untill now I assume that one of the problems
is that multible processes are "fighting" eachother for memory, and thus
working against eachother.

Regards
Anders Fugmann

Rik van Riel wrote:
> We don't know which additional memory the big task will
> need until we let it run a bit and do its page fault.
>
>
> Rik
> --
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
>
> http://www.surriel.com/ http://distro.conectiva.com/
>
> Send all your spam to aardvark@nl.linux.org (spam digging piggy)
>
>