From be4193108513f02439a211a92fd80e0651f6721b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 30 Nov 2011 21:21:45 +0100 Subject: IRC. --- open_issues/page_cache.mdwn | 73 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 open_issues/page_cache.mdwn (limited to 'open_issues/page_cache.mdwn') diff --git a/open_issues/page_cache.mdwn b/open_issues/page_cache.mdwn new file mode 100644 index 00000000..062fb8d6 --- /dev/null +++ b/open_issues/page_cache.mdwn @@ -0,0 +1,73 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, freenode, #hurd, 2011-11-28: + + youpi: would you find it reasonable to completely disable the page + cache in gnumach ? + i'm wondering if it wouldn't help make the system more stable + under memory pressure + assuming cache=writeback in gnumach? + because disabling the page cache will horribly hit performance + no, it doesn't have anything to do with the host + i'm not so sure + while observing the slab allocator, i noticed our page cache is + not used that often + eeh? + apart from the damn 4000 limitation, I've seen it used + (and I don't why it wouldn't be used) + (e.g. for all parts of libc) + ah, no, libc would be kept open by ext2fs + taht's precisely because of the 4k limit + but e.g. .o file emitted during make + well, no + well, see the summary I had posted some time ago, the 4k limit + makes it completely randomized + and thus you lose locality + yes + but dropping the limit would just fix it + that's my point + which I had tried to do, and there were issues, you mentioned why + and (as usual), I haven't had anyu time to have a look at the issue + again + i'm just trying to figure out the pros and cons for having teh + current page cache implementation + but are you saying you tried with a strict limit of 0 ? + non, I'm saying I tried with no limit + but then memory fills up + yes + so trying to garbage collect + i tried that too, the system became unstable very quickly + but refs don't falldown to 0, you said + did i ? + or maybe somebody else + see the list archives + that's possible + i'd imagine someone like sergio lopez + possibly + somebody that knows memory stuff way better than me in any case + youpi: i'm just wondering how much we'd loose by disabling the + page cache, and if we actually gain more stability (and ofc, if it's + worth it) + no idea, measures will tell + fixing the page cache shouldn't be too hard I believe, however + you just need to know what you are doing, which I don't + I do believe the cache is still at least a bit useful + even if dumb because of randomness + e.g. running make lib in the glibc tree gets faster on second time + because the cache wouldbe filled at least randomly with glibc tree + stuff + yes, i agree on that + braunr: btw, the current stability is fine for the buildds + restarting them every few days is ok + so I'd rather keep the performance :) + ok -- cgit v1.2.3