On Tue, Nov 29, 2016 at 10:11:34AM +0100, Thomas Schwinge wrote:
> Early after a system reboot (second run of the executable), I ran into a
> GNU Mach "panic ../vm/vm_page.c:2058: vm_page_evict: vm_page: unable to
> recycle any page"; see attached. As this is new code in GNU Mach (commit
> 5d12584
Hi!
On Mon, 28 Nov 2016 19:55:20 +0100, Samuel Thibault
wrote:
> Thomas Schwinge, on Mon 28 Nov 2016 17:10:26 +0100, wrote:
> > ..., but on the new ("bad") system, the first non-sensical (huge;
> > -2147479552 is 0x80001000) vm_allocate call actually succeeds:
>
> Yes, the userland address spac
Hello,
Thomas Schwinge, on Mon 28 Nov 2016 17:10:26 +0100, wrote:
> ..., but on the new ("bad") system, the first non-sensical (huge;
> -2147479552 is 0x80001000) vm_allocate call actually succeeds:
Yes, the userland address space is now 3G again, so it can now indeed
allocate that much.
> I hav
_limits call, which I'll try to figure
> out what it does.
That uses setrlimit for RLIMIT_DATA, RLIMIT_RSS, RLIMIT_VMEM, RLIMIT_AS,
but there is no change with that call removed.
> But nevertheless, unreclaimed swap space upon process
> termination sounds like a bug?
>
> Unle
Hello,
Thomas Schwinge, on Mon 28 Nov 2016 16:03:44 +0100, wrote:
> But nevertheless, unreclaimed swap space upon process
> termination sounds like a bug?
It's actually not really a new problem. It has just been emphasized
more with recent memory management changes.
Samuel
On Mon, Nov 28, 2016 at 04:03:44PM +0100, Thomas Schwinge wrote:
> Unless this a known issue, or somebody can quickly pinpoint the problem,
> I'll try to bisect core system packages, between the version of the
> "good" and "bad" disk images.
It's a known issue, a side effect of the page cache chan
esn't look very spectacular -- apart from
maybe the __gnu_test::set_memory_limits call, which I'll try to figure
out what it does. But nevertheless, unreclaimed swap space upon process
termination sounds like a bug?
Unless this a known issue, or somebody can quickly pinpoint the problem,
I