4

There is a question in the xv6 book which bothers me for a long time, and I wondered if anyone would like to clarify on this

KERNBASE limits the amount of memory a single process can use, which might be irritating on a machine with a full 4 GB of RAM. Would raising KERNBASE allow a process to use more memory?

In my opinion the answer to this question is no, since the whole mechanism around xv6 is designed to work with KERNBASE on a specific address space.

Thanks for any answer.

Yam Marcovic
  • 7,467
  • 25
  • 37
Lior Naar
  • 85
  • 1
  • 7

2 Answers2

4

Well, there is an issue here.

All physical addresses which are supposed to be used are mapped to virtual addresses 0x80000000 and up.

So, if you move KERNBASE upawards, the OS can use less physical memory.

Morass
  • 303
  • 1
  • 5
3

I've been thinking about this as well. Here are my conclusions—though I can't really vouch for them. It's mostly deductive.

The first thing is that your proposed explanation is technically wrong. xv6 can work with both higher and lower KERNBASE values. You can test this by changing KERNBASE to, say, 0x90000000 and then changing the relevant value in kernel.ld (the linker script which puts things in expected addresses).

The real issue here, as far as I've been able to gather, is that xv6 doesn't do any paging to disk. Now, remember that in xv6 addresses 0x80000000 (KERNBASE) and up map linearly to 0x00000000..0xffffffff. This means that any byte of memory you allocate in the whole system maps to 2 different physical addresses in 32-bit space. Since xv6 does no paging to disk, this means that if it allocates memory for the user process (using the sbrk() system call, used by malloc() in userspace), then it keeps it around in memory the whole time. So again, since we have 2 "copies", or more precisely 2 mappings to the same address, we can't ever actually use more than half the memory available in 32-bit address space.

Now, recall that KERNBASE is defined as 0x80000000, which is exactly that: half of the available memory. So no, raising KERNBASE under these conditions can't give us more userspace memory.

Yam Marcovic
  • 7,467
  • 25
  • 37
  • you will have to fix the v2p and p2v functions if you change KERNBASE – Morass Mar 02 '16 at 17:20
  • @Morass Fix how? They use the macro in their definition. – Yam Marcovic Mar 02 '16 at 17:27
  • I'm not sure I follow your reasoning. KERNBASE was chosen somewhat arbitrarily if I understand it correctly. Yes it maps the addresses starting from KERNBASE to lower addresses, but the only point of it is so that the kernel can live in physical memory even if there's no available memory at those high addresses. Now, assume we have full 4 Gbs. Since the kernel does not occupy 2Gbs, KERNBASE can be safely moved up to the point of (4Gb - sizeof(kernel)), which should leave the rest of available physical memory for processes. – Ivan Ivanov Mar 01 '20 at 06:44