RGBCube/serenity
1
Fork 0
mirror of https://github.com/RGBCube/serenity synced 2025-07-25 16:17:45 +00:00
Code Issues Activity Actions

Kernel: Use more fine-grained content data block granularity in TmpFS

Browse source 
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:
Liav A 2022-09-09 06:58:44 +03:00 • committed by Linus Groh
parent e8bdd885a3
commit b9dca3300e
3 changed files with 164 additions and 55 deletions
Download patch file Download diff file Expand all files Collapse all files

6
Tests/LibC/TestIo.cpp
View file

@ -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);