Do not duplicate data when unpacking bootfs #977
Comments
wkozaczuk
pushed a commit
to wkozaczuk/osv
that referenced
this issue
Aug 23, 2018
This patch optimizes RAM utilization of bootfs by eliminating unnecessary copy of data. It does so by pointing created file nodes to existing data offset in memory which is part of area where kernel is copied after decompression. In essence we add new flag rn_owns_buf to RAMFS ramfs_node to track if we can actually free memory wherever it happens. By default rn_owns_buf is set to true but new function ramfs_set_file_data called from unpack_bootfs() sets it to false. The savings of RAM are equal to the size of build/release/bootfs.bin which means we save around 700K with ZFS images, 0 with ROSF and as much as application code size with RAMFS where the improvement is most significant especially with for example Java images. Please note that file data referenced by nodes created during unpack_bootfs() would point to wherever bootfs.bin data is in the uncompressed kernel area which means it is most likely not aligned which possibly means slower access. This could be improved by making individual files aligned in bootfs.bin. Fixes cloudius-systems#977 Signed-off-by: Waldemar Kozaczuk <[email protected]> Message-Id: <[email protected]>
wkozaczuk
added a commit
to wkozaczuk/osv
that referenced
this issue
Aug 27, 2018
This patch optimizes RAM utilization of bootfs by eliminating unnecessary copy of data. It does so by pointing created file nodes to existing data offset in memory which is part of area where kernel is copied after decompression. In essence we add new flag rn_owns_buf to RAMFS ramfs_node to track if we can actually free memory whenever it happens. By default rn_owns_buf is set to true but new function ramfs_set_file_data called from unpack_bootfs() sets it to false. The savings of RAM are equal to the size of build/release/bootfs.bin which means we save around 700K with ZFS images, 0 with ROSF and as much as application code size with RAMFS where the improvement is most significant especially with Java images. Please note that file data referenced by nodes created during unpack_bootfs() would point to wherever bootfs.bin data is in the uncompressed kernel area which means it is most likely not aligned which possibly means slower access. This could be improved by making individual files aligned in bootfs.bin. Fixes cloudius-systems#977 Signed-off-by: Waldemar Kozaczuk <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When booting OSv initially mounts so called bootfs (ramfs at /) based on the data located in the kernel itself. It does it in unpack_bootfs which is essence copies the data from one place in memory to another (write).
In order to avoid this extra copy we could instead pass bootfs_start as the 'data' argument to sys_mount (https://github.com/cloudius-systems/osv/blob/master/fs/vfs/main.cc#L2191) which then could be used in ramfs_mount to populate ramfs flesystem is a similar way unpack_bootfs does it. Obviously unpack_bootfs does it through VFS and ramfs_mount would do it using native ramfs construct and do NOT copy file data instead simply set ramfs_node->rn_buf to the original address in the kernel.
The only caveat is that bootfs is read-write and a write to any file would result in at attempt of freeing the original data that is part of kernel which would be bad. One way to prevent it would be to mount bootfs as read-only (when calling sys_mount) so that VFS would not allow for any write operation. It actually makes a lot of sense given that bootfs typically contains executable code and possibly immutable data. If anybody wanted ramfs based OSv image with possibility of writing data (logs) it could mount read-write ramfs at different mountpoint.
This change would significantly improve memory utilization of ram disk based images of OSv especially when application code is pretty big.
The text was updated successfully, but these errors were encountered: