mirror of
https://github.com/RGBCube/serenity
synced 2025-07-25 16:17:45 +00:00
Kernel: Use more fine-grained content data block granularity in TmpFS
Instead of just having a giant KBuffer that is not resizeable easily, we use multiple AnonymousVMObjects in one Vector to store them. The idea is to not have to do giant memcpy or memset each time we need to allocate or de-allocate memory for TmpFS inodes, but instead, we can allocate only the desired block range when trying to write to it. Therefore, it is also possible to have data holes in the inode content in case of skipping an entire set of one data block or more when writing to the inode content, thus, making memory usage much more efficient. To ensure we don't run out of virtual memory range, don't allocate a Region in advance to each TmpFSInode, but instead try to allocate a Region on IO operation, and then use that Region to map the VMObjects in IO loop.
This commit is contained in:
parent
e8bdd885a3
commit
b9dca3300e
3 changed files with 164 additions and 55 deletions
|
@ -294,8 +294,7 @@ TEST_CASE(tmpfs_massive_file)
|
|||
[[maybe_unused]] auto ignored = strlcpy(buffer, "abcdefghijklmno", sizeof(buffer) - 1);
|
||||
|
||||
rc = write(fd, buffer, sizeof(buffer));
|
||||
EXPECT_EQ(rc, -1);
|
||||
EXPECT_EQ(errno, ENOMEM);
|
||||
EXPECT_EQ(rc, 16);
|
||||
|
||||
// ok now, write something to it, and try again
|
||||
rc = lseek(fd, 0, SEEK_SET);
|
||||
|
@ -307,10 +306,9 @@ TEST_CASE(tmpfs_massive_file)
|
|||
rc = lseek(fd, INT32_MAX, SEEK_SET);
|
||||
EXPECT_EQ(rc, INT32_MAX);
|
||||
|
||||
// FIXME: Should this return EOVERFLOW? Or is a 0 read fine?
|
||||
memset(buffer, 0, sizeof(buffer));
|
||||
rc = read(fd, buffer, sizeof(buffer));
|
||||
EXPECT_EQ(rc, 0);
|
||||
EXPECT_EQ(rc, 16);
|
||||
EXPECT(buffer != "abcdefghijklmno"sv);
|
||||
|
||||
rc = close(fd);
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue