summaryrefslogtreecommitdiff log msg author committer range
blob: fd503fdc11647fe9cb2991e449d94e8bdd2c31e3 (plain)
 ```1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 ``` ``````[[!meta copyright="Copyright © 2011, 2012 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]] [[!toc]] # 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 # [[gnumach_page_cache_policy]] ``````