On Mon, 26 Jun 2000, Andrea Arcangeli wrote:
> I proposed both (sync_page_buffers cames from 2.4.x, btw) but while
> they're stable and the free_before_allocate is a fix, I believe they're
> actually hurting performance.
> So the below patch reverse the `ret` thing for the apparent oom problem
> that I had. Again I don't care if mmap002 fails on 8mbyte box.
Andrea, people have had *databases* fail on big machines without
these patches.
I agree that we want better performance, but doing so at the
cost of stability simply isn't acceptable.
A few things we *could* do are:
- try to have most dirty pages flushed by kflushd
- get the small race back into __get_free_pages
(there's just about *no* chance we'll hit it)
- decrease the number of pages freed in try_to_free_pages
to something like 4 or 8 (still 4 times more than the
one we allocate)
- if (balance_dirty_state(NODEV) > 0), let kflushd do the
syncing instead of stalling in shrink_mmap (but wait
on bdflush and try the whole try_to_free_pages run again
if we failed because of dirty pages)
regards,
Rik
-- The Internet is not a network of computers. It is a network of people. That is its real strength.Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies http://www.conectiva.com/ http://www.surriel.com/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:07 EST