Search
Monday, 17th of December 2018, 21:21:08 UTC
0:24:25
stassats
joy, trying to fix one problem with run-program i discover another
0:48:39
stassats
somehow with-pinned-objects is not pinning hard enough
1:00:43
|3b|
ACTION wonders about that (pinning enough), though assumed it was just my code4 being broken :)
1:01:35
|3b|
actually, maybe i decided it was just syscalls being interrupted that was breaking things for me instead
1:03:46
stassats
eintr would explain this, but it gives me EFAULT
1:05:44
stassats
and the problem disappears when i use a static vector
1:08:27
stassats
it says EFAULT it doesn't say it's been moved
1:09:48
stassats
disabled page protection for GCing and it's working again
1:09:59
|3b|
ah, that would make sense too
1:11:10
stassats
that means you can never pass a lisp vector to the kernel
1:11:45
|3b|
but at least knowing that is better than not
1:12:23
stassats
so, need with-pinned and with-no-protection
1:13:24
stassats
suppose with-pinned implies no protection
1:24:17
stassats
protect_page_p does imply that, but not update_page_write_prot
1:27:44
stassats
now i can actually test my original problem
1:38:53
stassats
and remove without-gcing from run-program
1:39:46
stassats
run-program is abysmal
1:47:33
stassats
|3b|: you could try your syscalls again
1:49:13
|3b|
ACTION will try again if i ever get a working configuration :/
1:50:05
|3b|
(and was reasonably rare problem anyway, program doesn't GC too much)
1:50:17
stassats
yeah, i was gcing in a loop
1:50:36
stassats
but still, a rare problem is even worse
1:50:55
|3b|
yeah, will try to stress it when i have things running again
1:51:39
|3b|
though attempted stress changes things a lot since it is doing sort-of-realtime stuff
1:51:48
stassats
or you don't test it and hope i just fixed it
1:52:00
stassats
cause otherwise i'll have to fix something else again
1:52:24
stassats
i don't know about a bug => there's no bug
2:34:22
stassats
(loop (gc)) exhausting the heap is getting old
2:42:29
stassats
why can't that SB-KERNEL::*GC-EPOCH* be gced
2:54:09
stassats
for some reason each *gc-epoch* resides on its own page
2:55:51
stassats
why is it pinned for more than two calls to (gc)?
3:00:26
stassats
what happens if i write to the old *gc-epoch* cons
3:16:27
stassats
ok, each cons is residing on its own page, using a lot of pages but reporting a low number of bytes used, so it's never reaches the trigger
3:19:11
stassats
i think that's new after we wipe non pinned objects, effectively blowing up usages
3:19:35
stassats
i think the trigger should be changed to the number of pages used, not bytes allocated
3:25:20
stassats
or shouldn't bytes_allocated includes wasted space
3:35:01
pfdietz
This sounds important, and assuming you fix it it should go in monthly release notes.
3:35:29
stassats
eh, i'm not sure it's visible anywhere outside of (loop (gc)), a pathological case
3:35:38
stassats
but i'm using (loop (gc)) for testing
3:38:08
stassats
i suppose i need to prove that first
3:39:22
stassats
by trying to emulate what gc does
3:48:09
stassats
difficult, (loop (gc)) is just too perfect
Tuesday, 18th of December 2018, 9:21:08 UTC