Hi, If a process P has a dataspace (RAM) which it acquired from 'core', is there a way for it to split the dataspace so it can give some part to dataspace P2?
Daniel
Sorry, this should be "give some part to process P2". Anyhow, is the answer to use Rm_session and its dataspace method? Daniel
On Mon, 2013-04-29 at 18:59 -0700, Daniel Waddington wrote:
Hi, If a process P has a dataspace (RAM) which it acquired from 'core', is there a way for it to split the dataspace so it can give some part to dataspace P2?
Daniel
Hi Daniel,
Sorry, this should be "give some part to process P2". Anyhow, is the answer to use Rm_session and its dataspace method?
this would indeed work. But this solution comes at the cost of maintaining one RM session per dataspace. Depending on your use case, this might be quite expensive. E.g., if you want to virtualize core's RAM service per by allocating a large chunk of RAM at core and then handing out many small parts of this backing-store chunk as individual dataspaces, you will need to keep in mind that for each RM session, an RM client donates 64KiB of quota per RM session (see 'base/include/rm_session/connection.h') to core.
I think a way to create aliases for existing RAM dataspaces would be a handy feature. I am thinking in the lines of adding an interface like the following:
Dataspace_capability Ram_session::alias(Dataspace_capability dataspace, bool writable, off_t offset, size_t size);
This function would create a new dataspace capability that refers to a subrange of the specified 'dataspace'. In addition to accommodate your use case, the 'writable' argument would further allow for downgrading the write-permission of a RAM dataspace to read-only. So RAM dataspaces can effectively turned into ROM dataspaces, which is a feature sorely missing in the current API.
That said, there are some obstacles that hindered me to implement this feature yet. First, it will never work perfectly on base-linux, where each dataspace is represented by a file descriptor. As far as I know, there is no way to create an FD for a part of a file. Consequently, the aliased dataspace will need to refer to the original dataspace FD. So a process who obtains an alias will be able to access the original one. (i.e., reverting the downgrade of permissions)
Second, this feature will add complexity to the RAM service in core. Right now, dataspaces always refer to disjoint physical RAM areas, which will no longer be the case. One particular question is how to handle the lifetime of dataspaces and aliased dataspaces. Are aliases destroyed automatically if the original dataspace is freed? Or does each alias represent a first-class RAM dataspace? The latter solution would be nice interface-wise but quite complicated to implement. When freeing one of them, we would need to take care to release only those parts of physical RAM that are not referred to by any other alias. I have to think about that more thoroughly.
That said, those problems can definitely be solved and a feature like that is important to have.
In any case, the RM session mechanism you mentioned can emulate the aliasing feature right now (its just expensive). So I recommend using this mechanism as a stop-gap solution.
Cheers Norman
Hi Norman, As always, thanks for your guidance and quick feedback. For our current purpose the overhead of using RM session is OK since the application itself manages large chunks of memory. The alias API would be really nice though.
Best, Daniel
On Tue, 2013-04-30 at 18:18 +0200, Norman Feske wrote:
Hi Daniel,
Sorry, this should be "give some part to process P2". Anyhow, is the answer to use Rm_session and its dataspace method?
this would indeed work. But this solution comes at the cost of maintaining one RM session per dataspace. Depending on your use case, this might be quite expensive. E.g., if you want to virtualize core's RAM service per by allocating a large chunk of RAM at core and then handing out many small parts of this backing-store chunk as individual dataspaces, you will need to keep in mind that for each RM session, an RM client donates 64KiB of quota per RM session (see 'base/include/rm_session/connection.h') to core.
I think a way to create aliases for existing RAM dataspaces would be a handy feature. I am thinking in the lines of adding an interface like the following:
Dataspace_capability Ram_session::alias(Dataspace_capability dataspace, bool writable, off_t offset, size_t size);
This function would create a new dataspace capability that refers to a subrange of the specified 'dataspace'. In addition to accommodate your use case, the 'writable' argument would further allow for downgrading the write-permission of a RAM dataspace to read-only. So RAM dataspaces can effectively turned into ROM dataspaces, which is a feature sorely missing in the current API.
That said, there are some obstacles that hindered me to implement this feature yet. First, it will never work perfectly on base-linux, where each dataspace is represented by a file descriptor. As far as I know, there is no way to create an FD for a part of a file. Consequently, the aliased dataspace will need to refer to the original dataspace FD. So a process who obtains an alias will be able to access the original one. (i.e., reverting the downgrade of permissions)
Second, this feature will add complexity to the RAM service in core. Right now, dataspaces always refer to disjoint physical RAM areas, which will no longer be the case. One particular question is how to handle the lifetime of dataspaces and aliased dataspaces. Are aliases destroyed automatically if the original dataspace is freed? Or does each alias represent a first-class RAM dataspace? The latter solution would be nice interface-wise but quite complicated to implement. When freeing one of them, we would need to take care to release only those parts of physical RAM that are not referred to by any other alias. I have to think about that more thoroughly.
That said, those problems can definitely be solved and a feature like that is important to have.
In any case, the RM session mechanism you mentioned can emulate the aliasing feature right now (its just expensive). So I recommend using this mechanism as a stop-gap solution.
Cheers Norman
One last issue in doing this... I create the sub_rm and test it in the creating process, this works fine. When I try to send out the Dataspace_capability (as either ref or ptr) for the sub_rm through RPC to another process, then I get an invalid capability on the recv side (as determined by .valid()).
Is there something I'm missing here? Daniel
On Tue, 2013-04-30 at 10:13 -0700, Daniel Waddington wrote:
Hi Norman, As always, thanks for your guidance and quick feedback. For our current purpose the overhead of using RM session is OK since the application itself manages large chunks of memory. The alias API would be really nice though.
Best, Daniel
On Tue, 2013-04-30 at 18:18 +0200, Norman Feske wrote:
Hi Daniel,
Sorry, this should be "give some part to process P2". Anyhow, is the answer to use Rm_session and its dataspace method?
this would indeed work. But this solution comes at the cost of maintaining one RM session per dataspace. Depending on your use case, this might be quite expensive. E.g., if you want to virtualize core's RAM service per by allocating a large chunk of RAM at core and then handing out many small parts of this backing-store chunk as individual dataspaces, you will need to keep in mind that for each RM session, an RM client donates 64KiB of quota per RM session (see 'base/include/rm_session/connection.h') to core.
I think a way to create aliases for existing RAM dataspaces would be a handy feature. I am thinking in the lines of adding an interface like the following:
Dataspace_capability Ram_session::alias(Dataspace_capability dataspace, bool writable, off_t offset, size_t size);
This function would create a new dataspace capability that refers to a subrange of the specified 'dataspace'. In addition to accommodate your use case, the 'writable' argument would further allow for downgrading the write-permission of a RAM dataspace to read-only. So RAM dataspaces can effectively turned into ROM dataspaces, which is a feature sorely missing in the current API.
That said, there are some obstacles that hindered me to implement this feature yet. First, it will never work perfectly on base-linux, where each dataspace is represented by a file descriptor. As far as I know, there is no way to create an FD for a part of a file. Consequently, the aliased dataspace will need to refer to the original dataspace FD. So a process who obtains an alias will be able to access the original one. (i.e., reverting the downgrade of permissions)
Second, this feature will add complexity to the RAM service in core. Right now, dataspaces always refer to disjoint physical RAM areas, which will no longer be the case. One particular question is how to handle the lifetime of dataspaces and aliased dataspaces. Are aliases destroyed automatically if the original dataspace is freed? Or does each alias represent a first-class RAM dataspace? The latter solution would be nice interface-wise but quite complicated to implement. When freeing one of them, we would need to take care to release only those parts of physical RAM that are not referred to by any other alias. I have to think about that more thoroughly.
That said, those problems can definitely be solved and a feature like that is important to have.
In any case, the RM session mechanism you mentioned can emulate the aliasing feature right now (its just expensive). So I recommend using this mechanism as a stop-gap solution.
Cheers Norman
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
OK, fixed it. The Rm_connection object was being destroyed and as a result invalidating the cap before it got marshaled.
Daniel
On Tue, 2013-04-30 at 12:34 -0700, Daniel Waddington wrote:
One last issue in doing this... I create the sub_rm and test it in the creating process, this works fine. When I try to send out the Dataspace_capability (as either ref or ptr) for the sub_rm through RPC to another process, then I get an invalid capability on the recv side (as determined by .valid()).
Is there something I'm missing here? Daniel
On Tue, 2013-04-30 at 10:13 -0700, Daniel Waddington wrote:
Hi Norman, As always, thanks for your guidance and quick feedback. For our current purpose the overhead of using RM session is OK since the application itself manages large chunks of memory. The alias API would be really nice though.
Best, Daniel
On Tue, 2013-04-30 at 18:18 +0200, Norman Feske wrote:
Hi Daniel,
Sorry, this should be "give some part to process P2". Anyhow, is the answer to use Rm_session and its dataspace method?
this would indeed work. But this solution comes at the cost of maintaining one RM session per dataspace. Depending on your use case, this might be quite expensive. E.g., if you want to virtualize core's RAM service per by allocating a large chunk of RAM at core and then handing out many small parts of this backing-store chunk as individual dataspaces, you will need to keep in mind that for each RM session, an RM client donates 64KiB of quota per RM session (see 'base/include/rm_session/connection.h') to core.
I think a way to create aliases for existing RAM dataspaces would be a handy feature. I am thinking in the lines of adding an interface like the following:
Dataspace_capability Ram_session::alias(Dataspace_capability dataspace, bool writable, off_t offset, size_t size);
This function would create a new dataspace capability that refers to a subrange of the specified 'dataspace'. In addition to accommodate your use case, the 'writable' argument would further allow for downgrading the write-permission of a RAM dataspace to read-only. So RAM dataspaces can effectively turned into ROM dataspaces, which is a feature sorely missing in the current API.
That said, there are some obstacles that hindered me to implement this feature yet. First, it will never work perfectly on base-linux, where each dataspace is represented by a file descriptor. As far as I know, there is no way to create an FD for a part of a file. Consequently, the aliased dataspace will need to refer to the original dataspace FD. So a process who obtains an alias will be able to access the original one. (i.e., reverting the downgrade of permissions)
Second, this feature will add complexity to the RAM service in core. Right now, dataspaces always refer to disjoint physical RAM areas, which will no longer be the case. One particular question is how to handle the lifetime of dataspaces and aliased dataspaces. Are aliases destroyed automatically if the original dataspace is freed? Or does each alias represent a first-class RAM dataspace? The latter solution would be nice interface-wise but quite complicated to implement. When freeing one of them, we would need to take care to release only those parts of physical RAM that are not referred to by any other alias. I have to think about that more thoroughly.
That said, those problems can definitely be solved and a feature like that is important to have.
In any case, the RM session mechanism you mentioned can emulate the aliasing feature right now (its just expensive). So I recommend using this mechanism as a stop-gap solution.
Cheers Norman
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
Daniel Waddington -
Norman Feske