[PATCH] Start using memory below kernel

[Waldemar Kozaczuk]

This patch improves memory utilization by
making OSv use area below where kernel is loaded.

This normally saves only 1M + 640K (low memory)
howewer makes bigger difference when kernel_base in
Makefile is bumped higher. So if one changes kernel_base
to 10M then before this patch we would waste almost 10M of
memory.

Fixes #1012

Signed-off-by: Waldemar Kozaczuk <jwkoz...@gmail.com>
---
arch/x64/arch-setup.cc | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x64/arch-setup.cc b/arch/x64/arch-setup.cc
index 9317dd25..62236486 100644
--- a/arch/x64/arch-setup.cc
+++ b/arch/x64/arch-setup.cc
@@ -130,7 +130,7 @@ void arch_setup_free_memory()
// freed.
for_each_e820_entry(e820_buffer, e820_size, [] (e820ent ent) {
// can't free anything below edata, it's core code.
- // FIXME: can free below 2MB.
+ // can't free anything below kernel at this moment
if (ent.addr + ent.size <= edata) {
return;
}
@@ -159,6 +159,16 @@ void arch_setup_free_memory()
// now that we have some free memory, we can start mapping the rest
mmu::switch_to_runtime_page_tables();
for_each_e820_entry(e820_buffer, e820_size, [] (e820ent ent) {
+ //
+ // Free the memory below elf_start which we could not before
+ if (ent.addr < (u64)elf_start) {
+ if (ent.addr + ent.size >= (u64)elf_start) {
+ ent = truncate_above(ent, (u64) elf_start);
+ }
+ mmu::free_initial_memory_range(ent.addr, ent.size);
+ return;
+ }
+ //
// Ignore memory already freed above
if (ent.addr + ent.size <= initial_map) {
return;
@@ -167,7 +177,7 @@ void arch_setup_free_memory()
ent = truncate_below(ent, initial_map);
}
for (auto&& area : mmu::identity_mapped_areas) {
- auto base = reinterpret_cast<void*>(get_mem_area_base(area));
+ auto base = reinterpret_cast<void*>(get_mem_area_base(area));
mmu::linear_map(base + ent.addr, ent.addr, ent.size, ~0);
}
mmu::free_initial_memory_range(ent.addr, ent.size);
--
2.20.1

[Commit Bot]

From: Waldemar Kozaczuk <jwkoz...@gmail.com>
Committer: Nadav Har'El <n...@scylladb.com>
Branch: master

Start using memory below kernel

This patch improves memory utilization by
making OSv use area below where kernel is loaded.

This normally saves only 1M + 640K (low memory)
howewer makes bigger difference when kernel_base in
Makefile is bumped higher. So if one changes kernel_base
to 10M then before this patch we would waste almost 10M of
memory.

Fixes #1012

Signed-off-by: Waldemar Kozaczuk <jwkoz...@gmail.com>

Message-Id: <20190605043342.3...@gmail.com>

---
diff --git a/arch/x64/arch-setup.cc b/arch/x64/arch-setup.cc

[Nadav Har'El]

On Wed, Jun 5, 2019 at 7:33 AM Waldemar Kozaczuk <jwkoz...@gmail.com> wrote:

This patch improves memory utilization by
making OSv use area below where kernel is loaded.

This normally saves only 1M + 640K (low memory)
howewer makes bigger difference when kernel_base in
Makefile is bumped higher. So if one changes kernel_base
to 10M then before this patch we would waste almost 10M of
memory.

Fixes #1012

Thanks. I committed this, and tested that it actually allows me to run my favorite application (rogue ;-))

with 1MB less.

I'm curious if there isn't a problem with the physical address "0".  Is it ok that we go all the way to 0, or

does this code only starts somewhere else (I don't remember any details about this code... sorry...).

--
You received this message because you are subscribed to the Google Groups "OSv Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/20190605043342.31586-1-jwkozaczuk%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Waldek Kozaczuk]

On Tuesday, June 11, 2019 at 1:12:04 PM UTC-4, Nadav Har'El wrote:

On Wed, Jun 5, 2019 at 7:33 AM Waldemar Kozaczuk <jwkoz...@gmail.com> wrote:

This patch improves memory utilization by
making OSv use area below where kernel is loaded.

This normally saves only 1M + 640K (low memory)
howewer makes bigger difference when kernel_base in
Makefile is bumped higher. So if one changes kernel_base
to 10M then before this patch we would waste almost 10M of
memory.

Fixes #1012

Thanks. I committed this, and tested that it actually allows me to run my favorite application (rogue ;-))

with 1MB less.

I'm curious if there isn't a problem with the physical address "0".  Is it ok that we go all the way to 0, or

does this code only starts somewhere else (I don't remember any details about this code... sorry...).

I had the same thought.

I have just looked at ```page_pool::free_initial_memory_range``` :

void free_initial_memory_range(void* addr, size_t size)

{

    if (!size) {

        return;

    }

    if (addr == nullptr) {

        ++addr;

        --size;

    }

    auto a = reinterpret_cast<uintptr_t>(addr);

    auto delta = align_up(a, page_size) - a;

    if (delta > size) {

        return;

    }

    addr += delta;

    size -= delta;

    size = align_down(size, page_size);

    if (!size) {

        return;

    }

    on_new_memory(size);

    on_free(size);

    auto pr = new (addr) page_range(size);

    free_page_ranges.initial_add(pr);

}

And it seems to a handle addr 0 (the range 0-640KiB) but I think there may be a bug in there - it bumps addr by 1, but the size should be decremented by 8 not 1, am I wrong?

 

To unsubscribe from this group and stop receiving emails from it, send an email to osv...@googlegroups.com.

[Waldek Kozaczuk]

I think that code is correct. In general the arithmetic on void* is not allowed. But in GNU C/C++ void size is assumed as char. So it looks like ++addr increments the address by 1 not 8 as I was guessing. Therefore size— seems to be correct. 

Then the code seem to align up the address by single page so in reality we are going to be starting at 0x1000, right?

Sent from my iPhone

You received this message because you are subscribed to a topic in the Google Groups "OSv Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/osv-dev/Lfj3IbO7ges/unsubscribe.
To unsubscribe from this group and all its topics, send an email to osv-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/a2f06ade-cec4-47a5-91ff-552000871dd5%40googlegroups.com.

[Nadav Har'El]

On Tue, Jun 11, 2019 at 10:01 PM Waldek Kozaczuk <jwkoz...@gmail.com> wrote:

I think that code is correct. In general the arithmetic on void* is not allowed. But in GNU C/C++ void size is assumed as char. So it looks like ++addr increments the address by 1 not 8 as I was guessing. Therefore size— seems to be correct. 

Then the code seem to align up the address by single page so in reality we are going to be starting at 0x1000, right?

Right. It seems correct.

To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/6A65BFC4-143C-4F4E-9E67-3083A23AF6E4%40gmail.com.