On 2.8.2012 1:35, Jiří Zárevúcky wrote: > On 2 August 2012 00:54, Jakub Jermar <[email protected]> wrote: >> On 08/01/2012 07:55 PM, Jiří Zárevúcky wrote: >>> We could implement some kind of reservation system. >>> That is, application would call something like as_area_reserve() to >>> reserve just a piece of virtual address space, not physical memory. >>> Then there would be another call distinct from as_area_create() that >>> would map pages in a previously reserved region. Is there a way to >>> handle access to unmapped pages from userspace? >> >> Well, it already works like that. When you create a, say anonymous, >> address space area, only virtual address space is allocated. Physical >> memory is allocated only when the corresponding virtual page is first >> referenced. >> > > Not quite. What I'm talking about is reserving just virtual address space. > The way it works now is that it allocates address space and reserves > physical memory as well. If you have 100 MB of unmapped stack pages, > it still counts as 100 MB of used memory, since over-commitment is not > allowed. If you could over-commit, then solving the stack-growing part > wouldn't need any change at all.
Hm, I can see your point now. Memory reservations and stack memory do not fit together very well. On the other hand, the address space areas are responsible for their own memory reservations so it wouldn't be that difficult to introduce a flag for the anonymous backend that would prevent reserving stack memory in advance. The page fault handler in an area with this flag would simply try to allocate a new frame without previous reservation. If the allocation failed, it would simply kill the task. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
