summaryrefslogtreecommitdiff
path: root/open_issues/low_memory.mdwn
diff options
context:
space:
mode:
authorSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2015-02-18 00:58:35 +0100
commit49a086299e047b18280457b654790ef4a2e5abfa (patch)
treec2b29e0734d560ce4f58c6945390650b5cac8a1b /open_issues/low_memory.mdwn
parente2b3602ea241cd0f6bc3db88bf055bee459028b6 (diff)
Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"
This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.
Diffstat (limited to 'open_issues/low_memory.mdwn')
-rw-r--r--open_issues/low_memory.mdwn113
1 files changed, 113 insertions, 0 deletions
diff --git a/open_issues/low_memory.mdwn b/open_issues/low_memory.mdwn
new file mode 100644
index 00000000..22470c65
--- /dev/null
+++ b/open_issues/low_memory.mdwn
@@ -0,0 +1,113 @@
+[[!meta copyright="Copyright © 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 open_issue_glibc open_issue_hurd]]
+
+Issues relating to system behavior under memory pressure.
+
+[[!toc]]
+
+
+# [[gnumach_page_cache_policy]]
+
+
+# IRC, freenode, #hurd, 2012-07-08
+
+ <braunr> am i mistaken or is the default pager simply not vm privileged ?
+ <braunr> (which would explain the hangs when memory is very low)
+ <youpi> no idea
+ <youpi> but that's very possible
+ <youpi> we start it by hand from the init scripts
+ <braunr> actually, i see no way provided by mach to set that
+ <braunr> i'd assume it would set the property when a thread would register
+ itself as the default pager, but it doesn't
+ <braunr> i'll check at runtime and see if fixing helps
+ <youpi> thread_wire(host, thread, 1) ?
+ <youpi> ./hurd/mach-defpager/wiring.c: kr =
+ thread_wire(priv_host_port,
+ <braunr> no
+ <braunr> look in cprocs.c
+ <braunr> iir
+ <braunr> iirc
+ <braunr> iiuc, it sets a 1:1 kernel/user mapping
+ <youpi> ??
+ <youpi> thread_wire, not cthread_wire
+ <braunr> ah
+ <braunr> right, i'm getting tired
+ <braunr> youpi: do you understand the comment in default_pager_thread() ?
+ <youpi> well, I'm not sure to know what external vs internal is
+ <braunr> i'm almost sure the default pager is blocked because of a relation
+ with an unprivlege thread
+ <braunr> +d
+ <braunr> when hangs happen, the pageout daemon is still running, waiting
+ for an event so he can continue
+ <braunr> it*
+
+ <braunr> all right, our pageout stuff completely sucks
+ <braunr> when you think the system is hanged, it's actually not
+ <pinotree> and what's happening instead?
+ <braunr> instead, it seems it's in a very complex resursive state which
+ ends in the slab allocator not being able to allocate kernel map entries
+ <braunr> recursive*
+ <braunr> the pageout daemon, unable to continue, progressively slows
+ <braunr> in hope the default pager is able to service the pageout requests,
+ but it's not
+ <braunr> probably the most complicated deadlock i've seen :)
+ <braunr> luckily !
+ <braunr> i've been playing with some tunables involved in waking up the
+ pageout daemon
+ <braunr> and got good results so far
+ <braunr> (although it's clearly not a proper solution)
+ <braunr> one thing the kernel lacks is a way to separate clean from dirty
+ pages
+ <braunr> this stupid kernel doesn't try to free clean pages first .. :)
+ <braunr> hm
+ <braunr> now i can see the system recover, but some applications are still
+ stuck :(
+ <braunr> (but don't worry, my tests are rather aggressive)
+ <braunr> what i mean by aggressive is several builds and various dd of a
+ few hundred MiB in parallel, on various file systems
+ <braunr> so far the file systems have been very resilient
+ <braunr> ok, let's try running the hurd with 64 MiB of RAM
+ <braunr> after some initial swapping, it runs smoothly :)
+ <braunr> uh ?
+ <braunr> ah no, i'm still doing my parallel builds
+ <braunr> although less
+ <braunr> gcc: internal compiler error: Resource lost (program as)
+ <braunr> arg
+ <braunr> lol
+ <braunr> the file system crashed under the compiler
+ <pinotree> too much memory required during linking? or ram+swap should have
+ been enough?
+ <braunr> there is a lot of swap, i doubt it
+ <braunr> the hurd is such a dumb and impressive system at the same time
+ <braunr> pinotree: what does this tell you ?
+ <braunr> git: hurdsig.c:948: post_signal: Unexpected error: (os/kern)
+ failure.
+ <pinotree> something samuel spots often during the builds of haskell
+ packages
+
+Probably also the *sigpost* case mentioned in [[!message-id
+"87bol6aixd.fsf@schwinge.name"]].
+
+ <braunr> actually i should be asking jkoenig
+ <braunr> it seems the lack of memory has a strong impact on signal delivery
+ <braunr> which is bad
+ <antrik> braunr: I have a vague recollection of slpz also saying something
+ about missing dirty page tracking a while back... I might be confusing
+ stuff though
+ <braunr> pinotree: yes it happens often during links
+ <braunr> which makes sense
+ <pinotree> braunr: "happens often" == "hurdsig.c:948: post_signal: ..."?
+ <braunr> yes
+ <pinotree> if you can reproduce it often, what about debugging it? :P
+ <braunr> i mean, the few times i got it, it was often during a link :p
+ <braunr> i'd rather debug the pageout deadlock :(
+ <braunr> but it's hard