Re: Ongoing 2.4 VM suckage

[Anders Peter Fugmann <afu@fugmann.dhs.org>]

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)
> 
>