On Sun, 25 Jun 2000, Rik van Riel wrote:
>Andrea, people have had *databases* fail on big machines without
>these patches.
I need to know more details about these failing databases. Is these people
running databases without enough memory? Are they swapping out? how much
memory do they have and how much memory uses the db? also make 200% sure
they're using _stock_ 2.2.15, if something fails with a binary-vendor
kernel that is offtopic here.
If swap is not perfectly reliable I don't think we should matter if fixing
that means to hurt machines with enough memory. (talking about 2.2.x
indeed)
I for sure want to fix the free_before_allocat thing, but for now no-fix
is probably better than suboptimal fix IMHO. While the machine doesn't
implode, it may sometime do more work than necessary. I think it's
possible to fix it also in 2.2.x but not in a hurry (something for a pre1
patch).
>- get the small race back into __get_free_pages
> (there's just about *no* chance we'll hit it)
We agree on this and that was my main concern.
>- 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)
If we have to wait anyway (for bdflush) it's much better we do the I/O
ourself as now no? Repeating things looks always risky but I'll think
about it and about the other points.
Many thanks for the feedback!
Andrea
-
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