Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Mar 2010 13:33:15 -0700
From:      Richard Henderson <rth@twiddle.net>
To:        Juergen Lock <nox@jelal.kn-bremen.de>
Cc:        Blue Swirl <blauwirbel@gmail.com>, freebsd-emulation@freebsd.org, Toni <tonygio04@gmail.com>, qemu-devel@nongnu.org, Andreas Tobler <andreast@fgznet.ch>
Subject:   Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel	 port update for testing
Message-ID:  <4BB2600B.90002@twiddle.net>
In-Reply-To: <201003302009.o2UK9lAv002282@triton8.kn-bremen.de>
References:  <20100325204423.GA46954@triton8.kn-bremen.de>	<f43fc5581003301104x77c0e527m871b035a7364bd5b@mail.gmail.com>	<20100330191629.GA95521@triton8.kn-bremen.de> <201003302009.o2UK9lAv002282@triton8.kn-bremen.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On 03/30/2010 01:09 PM, Juergen Lock wrote:
> Oh sorry if that was not clear, things go into swap if I _replace_ the
> endaddr ~0ul (which caused the assert) with the max value the assert
> still tolerates i.e.
> 	((abi_ulong)1 << L1_MAP_ADDR_SPACE_BITS) - 1
> which in this case seems to be 0x7fffffffffff:

Yes, I got that.  And I see from ...

> #3  0x0000000060012731 in page_set_flags (start=140737488224256, 
>     end=18446744073709551615, flags=32)

... here that the range we're reserving is

  0x7ffffffe0000 ... 0x7fffffffffff

which is a mere 128k range.  Which ought to allocate no more than
a single leaf page table (and thus N-1 pages for the N-level table).

Which doesn't answer the question of why you'd wind up running out
of memory.


r~



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BB2600B.90002>