Lars Heidieker <lars%heidieker.de@localhost> writes: > One problem I see with the patch is, if applied the pagedaemon gives up > pool_draining after the first call to pool_drain that doesn't free > anything. pool_drain drains one and only one pool per call, so chance > are good that we stop to early. (I realize the patch Richard posted has some -6/-current issues in naming, calling pool_drain_end instead of pool_drain. I am fixing them; I was going to do a test build and boot the modified kernel before commiting.) Reading your note again, I might have replied too quickly. Two questions: How hard do you think it would be to make pool_drain() keep trying pools until one succeeded in freeing something (or it tried them all)? Do you see any downside in that change? It seems like it's just as well to more aggressively try to free memory when we are out. If a pool frees something, it will stop, so it's only when pools do not give back any space that it will take longer. The round-robin nature seems to be built in. It seems perhaps tricky to retain the round-robin nature and allow a full cycle; it's not obvious to me that just remembering the current next pointer is ok, but I think it is. Do you think that the patch's change to sleep after a failed drain will cause a system to behave particularly badly? It's not clear to me how the pagedaemon gets woken up, and if it requires a new lwp to be wanting memory.
Attachment:
pgpBN9bQEMFgq.pgp
Description: PGP signature