* [RFC] pre cleaning (a more lucid description)
@ 2000-06-06 15:53 Ed Tomlinson
0 siblings, 0 replies; only message in thread
From: Ed Tomlinson @ 2000-06-06 15:53 UTC (permalink / raw)
To: linux-mm
Hi,
Sometimes I hate email. The previous message on precleaning was NOT intended
to be sent... Here is a better description. I have subscribed to linux-mm so
I will see any comments. BTW this is for 2.5 land.
This is an idea to help the mm subsystem. It uses a some IO bandwidth to speed up
gathering free pages. Simpily stated, the idea is: during the scan for free pages,
once we have found our quota, we should look ahead and write out dirty pages. The
next scan, if we have done things correctly, should have very few dirty pages to
write. It should be possible to make this process self tuning.
I assumed we are directly scanning the mm array
lets define a few items
Q a pointer or index to the place we stopped looking for free pages.
C a pointer or index to the place we stopped looking for pages to pre clean, note we always
restart the pre clean process at Q.
D a count of dirty pages, in the pre cleaned area (Q < C), we had to write gather our
quota of free pages.
P a count of dirty pages we pre cleaned since the last time we freed pages.
S a count of the number of pages we scaned to get our quota of free pages.
If things are working correctly D should be much less than P. This ratio
can be used to determine if we are helping. We should try to pre clean at
least S pages. The scan/preclean task needs to adjust its priority during
this process. It needs to be very high during the freeing cycle and low
during the preclean cycle. If the preclean process is unable to scan S
pages, we can use this as indication that we are short of resources.
A couple of comments. We do not have to write all dirty pages, just those
that the next scan will select as free. It may be possible to cluster the
writes.
The net effect of this should be that we do our page outs when they will
not effect processes. When we need free pages getting them should
be faster and usually will not require (much) IO.
Thoughts?
Ed Tomlinson <tomlins@cam.org>
http://www.cam.org/~tomlins/njpipes.html
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2000-06-06 15:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-06 15:53 [RFC] pre cleaning (a more lucid description) Ed Tomlinson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox