diff options
author | Thomas Schwinge <thomas@codesourcery.com> | 2014-02-26 12:43:40 +0100 |
---|---|---|
committer | Thomas Schwinge <thomas@codesourcery.com> | 2014-02-26 12:43:40 +0100 |
commit | ca63bd2d33b3d28eabd50ad58577b52a1fc9eba0 (patch) | |
tree | 74bf46806011262f116d83ff5bec0a1cf8a79a4b /open_issues/gnumach_page_cache_policy.mdwn | |
parent | 5757d0c3b11dac706fbe72247e9d2dcf0ff44df9 (diff) | |
parent | 7ffc398e1c386925826c42a30ff10ae84e79378f (diff) |
Merge remote-tracking branch 'dirichlet.SCHWINGE/master'
Diffstat (limited to 'open_issues/gnumach_page_cache_policy.mdwn')
-rw-r--r-- | open_issues/gnumach_page_cache_policy.mdwn | 60 |
1 files changed, 60 insertions, 0 deletions
diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn index 5e93887e..77e52ddb 100644 --- a/open_issues/gnumach_page_cache_policy.mdwn +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -811,3 +811,63 @@ License|/fdl]]."]]"""]] <braunr> have* <braunr> and even if laggy, it doesn't feel much more than the usual lag of a network (ssh) based session + + +# IRC, freenode, #hurd, 2013-10-08 + + <braunr> hmm i have to change what gnumach reports as being cached memory + + +## IRC, freenode, #hurd, 2013-10-09 + + <braunr> mhmm, i'm able to copy files as big as 256M while building debian + packages, using a gnumach kernel patched for maximum memory usage in the + page cache + <braunr> just because i used --sync=30 in ext2fs + <braunr> a bit of swapping (around 40M), no deadlock yet + <braunr> gitweb is a bit slow but that's about it + <braunr> that's quite impressive + <braunr> i suspect thread storms might not even be the cataclysmic event + that we thought it was + <braunr> the true problem might simply be parallel fs synces + + +## IRC, freenode, #hurd, 2013-10-10 + + <braunr> even with the page cache patch, memory filled, swap used, and lots + of cached objects (over 200k), darnassus is impressively resilient + <braunr> i really wonder whether we fixed ext2fs deadlock + + <braunr> youpi: fyi, darnassus is currently running a patched gnumach with + the vm cache changes, in hope of reproducing the assertion errors we had + in the past + <braunr> i increased the sync interval of ext2fs to 30s like we discussed a + few months back + <braunr> and for now, it has been very resilient, failing only because of + the lack of kernel map entries after several heavy package builds + <gg0> wait the latter wasn't a deadlock it resumed after 1363.06 s + <braunr> gg0: thread storms can sometimes (rarely) fade and let the system + resume "normally" + <braunr> which is why i increased the sync interval to 30s, this leaves + time between two intervals for normal operations + <braunr> otherwise writebacks are queued one after the other, and never + processed fast enough for that queue to become empty again (except + rarely) + <braunr> youpi: i think we should consider applying at least the sync + interval to exodar, since many DDs are just unaware of the potential + problems with large IOs + <youpi> sure + + <braunr> 222k cached objects (1G of cached memory) and darnassus is still + kicking :) + <braunr> youpi: those lock fixing patches your colleague sent last year + must have helped somewhere + <youpi> :) + + +## IRC, freenode, #hurd, 2013-10-13 + + <youpi> braunr: how are your tests going with the object cache? + <braunr> youpi: not so good + <braunr> youpi: it failed after 2 days of straight building without a + single error output :/ |