> In looking through the revised kswapd code it appears to me that under
> some circumstances the kswapd process would fail to sleep even after
> repeated failures, stopping only when the memory objective had been
> reached.
> Since the task state is set to TASK_INTERRUPTIBLE after the call to
> schedule(), a blocking call to try_to_free_page() could cause the state
> to get set back to TASK_RUNNING, which would cause it to fall through
> the next schedule() and do the loop again.
> It seems like this could account for some of the reports of
> overly-aggressive swapping in 2.1.89-5. Have I missed something here, or
> is this the intended behavior?
Hmmm, that could be the case, but I think it's more likely that the new
objective of kswapd to ensure there's at least 2 * 128KB chunks of memory
free is the more likely cause - notice the reports of this sort of failure
have come from people with large amounts of RAM (64 megs)? Under the
worst case senario, you might end up swapping 124KB out of each 128KB
chunk before successfully generating *one* 128KB block.
Not only that, but I think it would be prudent to add a committed memory
counter, and only allow mmap()ings to succeed if they don't overrun the
max-committed. The default behaviour could be to allow say 25%
overcommit, similar to what happens now. That way we can reasonably
return ENOMEM on systems with no swap, rather than randoming sending a
SIGSEGV later on.
-ben (who *really* hates anonymous mappings)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu