> 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.
This would explain why the hard disk chomps away sometimes, in a
repetetive sounding manner (sounds like ch clunk ch clunk ch clunk.. etc),
and during this time the system is completely blocked from doing anything.
Usually after a few seconds it comes back to life and everything is happy
(until a few minutes later or whenever when it decides to do it again).. I
started seeing this behaviour about the same time pre-2.1.89-1 came out,
but it was much much worse than pre-3.. (I havn't tried pre-5 yet because
I can't be bothered re-applying the irq diff, and the diffs to get smbfs
working, unless this has been fixed, and I assumed the swap code hasn't
been touched either)..
>
> 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?
I'd say you've hit the nail with the middle of the hammer, so to speak. :)
Cheers,
Dave.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu