From b687f782572b127e8ae32f0df40250fb19ccd22b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 25 Jul 2011 11:27:24 +0200 Subject: IRC. --- open_issues/placement_of_virtual_memory_regions.mdwn | 16 +++++++++++++++- open_issues/rm_fr.mdwn | 12 ++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-) diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn index 95b9e545..39478f20 100644 --- a/open_issues/placement_of_virtual_memory_regions.mdwn +++ b/open_issues/placement_of_virtual_memory_regions.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -IRC, freenode, #hurd, 2011-07-13 +# IRC, freenode, #hurd, 2011-07-13 does anyone know if posix (or mach) has requirements or a policy about the placement of allocations of virtual space ? @@ -87,3 +87,17 @@ IRC, freenode, #hurd, 2011-07-13 jkoenig: i really want to miss as little as possible on the vm part, so having detailed information about what actually happens on running hurd systems is something i need + + +# IRC, freenode, #hurd, 2011-07-24 + + oh btw, i noticed there are many mappings below the program text + most notably, the stack + except for special applications like wine, could this break + anything ? + i also wonder how libraries are mapped, because there is nothing + to perform top-down allocations + which means if the region below the program text is exhausted, + libraries could be mapped right after the heap + it shouldn't break anything except things like wine & libgc, yes + which could make malloc() fail :/ diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn index 89a803ab..aab52d97 100644 --- a/open_issues/rm_fr.mdwn +++ b/open_issues/rm_fr.mdwn @@ -25,3 +25,15 @@ really waits for all I/Os, which basically means strictly serializing file removals: remove one file, wait for the disk to have done it (~10ms), remove the next one, etc. I guess this is for safety reasons against crashes, but isn't the sync option there for such kind of + + +# IRC, freenode, #hurd, 2011-07-23 + + youpi: hm... async deletion does have one downside: I just removed + something to make space, and retried the other command immediately + afterwards, and it still said "no space left on device"... a few seconds + later (after the next regular sync I suppose?) it worked + well, that's sorta expected, yes + we get the same on Linux + Mmm, on second thought, I'm not sure how that can happen + the asynchronous thing is for disk writes, not cache writes -- cgit v1.2.3