Thanks Norman. I think I have a better understanding now. :)
-----Original Message----- From: Norman Feske [mailto:norman.feske@...1...] Sent: Monday, June 13, 2011 10:51 AM To: genode-main@lists.sourceforge.net Subject: Re: Data space creation and physical memory allocation strategy.
Hello Chen,
resources for each client. To do that, basically we need to allocate a "real" dataspace (i.e. get physical memory from backing store) and do
paging
upon a page fault. When the application runs out of its RAM, we can do a swap (a file system is probably needed for swapping), which is what Linux
is
doing.
exactly. But the possibilities go even further. For example, on a NUMA system, a special memory manager could provide a RAM service that migrates dataspaces transparently between local and non-local memory. Another use case would be a memory manager with support for large non-contiguous memory areas.
That said, the concept of managed dataspaces is not time tested yet. We still need a profound understanding of its use cases and possibly improve it. Right now, there is one important thing to keep in mind: each managed dataspace is a separate RM session. Therefore, a managed dataspace is not exactly cheap. The creation will traverse the process tree (in contrast to the allocation of RAM dataspaces) and each RM session must be paid for in terms of a quota donation. Hence, a managed dataspace makes sense for large memory objects but not as a means to manage containers of just a few memory pages.
As another limitation, this concept is not functional on 'base-linux' because Linux does not allow the manipulation of remote address spaces (at least, we do not know how to do it efficiently).
BTW, it looks like the current heap implementation did not use managed
data
space, and therefore, every malloc still leads to a physical memory allocation, right?
A process may never know whether its 'env()->ram_session()' (which is used as backing store by 'env()->heap()') refers to core's RAM service or not. The RAM session of the process could have been routed to another implementation (e.g., a swapping memory manager) of the RAM-session interface. For all current Genode scenarios, your observation is correct - each process indeed uses core's RAM service and thereby physical memory. But if we had an alternative RAM service implementation, we could make a process use this service by simply routing its RAM session to the alternative RAM service rather than the parent. No code modifications required.
Best regards Norman