Messages in this thread | | | Date | Wed, 28 Feb 2001 12:35:58 -0300 (BRST) | From | Rik van Riel <> | Subject | Re: [patch][rfc][rft] vm throughput 2.4.2-ac4 |
| |
On Wed, 28 Feb 2001, Marcelo Tosatti wrote: > On Wed, 28 Feb 2001, Mike Galbraith wrote:
> > That's one reason I tossed it out. I don't _think_ it should have any > > negative effect on other loads, but a test run might find otherwise. > > Writes are more expensive than reads. Apart from the aggressive read > caching on the disk, writes have limited caching or no caching at all if > you need security (journalling, for example). (I'm not sure about write > caching details, any harddisk expert?)
I suspect Mike needs to change his benchmark load a little so that it dirties only 10% of the pages (might be realistic for web and/or database loads).
At that point, you should be able to see that doing writes all the time can really mess up read performance due to extra introduced seeks.
We probably want some in-between solution (like FreeBSD has today). The first time they see a dirty page, they mark it as seen, the second time they come across it in the inactive list, they flush it. This way IO is still delayed a bit and not done if there are enough clean pages around.
Another solution would be to do some more explicit IO clustering and only flush _large_ clusters ... no need to invoke extra disk seeks just to free a single page, unless you only have single pages left.
regards,
Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...
http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |