On Thu, 15 Jun 2000, Andrea Arcangeli wrote:
> On Wed, 14 Jun 2000, Marcelo Tosatti wrote:
>
> >mmap002 on 2.2.15 gets killed. mmap002 on 2.2.15 + 2.2.16's
> >thrasing heuristic runs fine. Try it.
>
> If you look at the vmstat while mmap002 gets killed you'll
> notice the machine is really out of memory and the only complain
> you can make is that there's still a relevant amount of _dirty_
> cache in the machine.
Indeed. I didn't fix this because I couldn't see a way to do this
cleanly in 2.2...
> The free_before_allocate is necessary but it's not actually
> implemented correctly. I implemented it as suggested in my email
> of yesterday to l-k and all works just fine here as far I can
> tell. mtest -m 70 (on 128mbyte machine) from SCT works fine as
> my other swap testcases. Rik, I guess your machine imploded
> because you was increasing by mistake the free_before_allocate
> also inside the atomic_read(&free_before_allocate).
You're right here. My mistake...
> I found that the changes in do_try_to_free_pages are buggy
> because one task could make the cache freeable, the other task
> could free all the cache that now is been unmapped by the first
> task. The first task that made the cache freeable will be killed
> because when it tries to free the cache it won't succeed (even
> if the other task just freed all the cache and it made enough
> memory free for both processes). That happened here and we have
> to consider swap_out a progress too if we don't want to kill
> innocent task as could instead happen now.
I hadn't thought of this one because do_try_to_free_pages runs under
the big kernel lock, but of course, this could happen too...
And indeed, if we have the free_before_allocate logic, it isn't very
important if we actually freed a page or not ... as long as we make
progress and other tasks help us make more progress...
> Then kswapd shouldn't stop after a few passes but only if it fails to do
> any progress during its work as in 2.2.15 (so when it make no sense
> anymore to do the next pass very soon). Also running kswapd at once isn't
> going to improve performance. What's the problem you had with kswapd in
> 2.2.x that caused to add such hacks?
It wasn't a stability problem, but it's a _performance_ problem.
Running kswapd earlier has 2 effects:
1) we start doing non-agressive page aging before we run out
of memory -> better page replacement when you start to fill
up memory
2) freeing memory in the background when we're under low memory
pressure makes sure kswapd will never kick in with full
agression, this makes the machine run a little bit smoother
Remember that an agressive kswapd on a system without page aging
just isn't good...
> Then assign = 0 shouldn't be done at each pass, but we should
> refresh the swap_cnt stuff only at once per swap_out call or
> killing a task will take too much time due too high complexity
> of the algorithm (you may not see that complexity problem with
> 32mbyte of ram but you should see this with some giga of ram
> with some more pagetable to scan).
Eugmmmm, I don't see what you mean here...
> I'm implementing the write throttling thing now to see if then
> mmap002 survives than I'll post the whole patch with the
> do_try_to_free_pages and free_before_allocated fixes.
Cool, that should be interesting.
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:35 EST