about text-segment, invalidation in context switch and on-demand

[Paolo P]

1. So to make text-segment read-only don't I have to achieve that
through as_define_region. though I don't know I can approach this other
than make a flag to indicate its read-only or making this statement
"as->vaddr = vaddr & readable"


2. In every context switch it always calls as_activate to invalidate the
TLB. From my understanding, it should be invalidated if a new process is
created from fork, is it not?

3. Im confused about how to approach the on-demand loading. In loadelf,
it uses load_segment to load all the pages from the segment in memory. I
assume that I have to use alloc_kpages to allocate a page but I dont
know how to approach two things below without using load_segment

"Load the page, using information from the program’s ELF file to do so"

and

"Update OS/161’s information about this address space."


I appreciate the help in answering my questions

[cs350]

1. So to make text-segment read-only don't I have to achieve that through
as_define_region. though I don't know I can approach this other than make a
flag to indicate its read-only or making this statement "as->vaddr = vaddr &
readable"

As_define_region is just called to fill out segment information like size
and offset. You can ignore the readable/writeable/executable settings.

You should use the TLB dirty bit to make pages from the text
segment read-only.

2. In every context switch it always calls as_activate to invalidate the TLB.
From my understanding, it should be invalidated if a new process is created
from fork, is it not?

Yes, you should definitely adjust that behaviour so that invalidation only
happens when you switch between two different address spaces. Otherwise
your vm statistics will be bloated.

3. Im confused about how to approach the on-demand loading. In loadelf, it
uses load_segment to load all the pages from the segment in memory. I assume
that I have to use alloc_kpages to allocate a page but I dont know how to
approach two things below without using load_segment
"Load the page, using information from the program’s ELF file to do so"
and
"Update OS/161’s information about this address space."
I appreciate the help in answering my questions

The modifications to load_elf can be minimal. You should comment out the
load_segment call and replace it with a call to your own function which
simply saves the sizes and offsets somewhere for later use. You should
also save the vnode of the file.

-Alex

[Evgeny]

With regards to the TLB Invalidation - it was mentioned earlier that the
TLB should only be invalidated when switching between two address
spaces. However, I'm still unclear whether we should invalidate the TLB
on fork.

The answer below states: "Yes, you should definitely adjust that
behaviour so that invalidation only happens when you switch between two
different address spaces."

In other words - that's on every context switch, including on fork, is
it not? Otherwise, if we don't invalidate the TLB on fork, does this
mean we are not switching between two different address spaces when
forking a new thread?

Post by cs350

Post by Paolo P
1. So to make text-segment read-only don't I have to achieve that
through as_define_region. though I don't know I can approach this
other than make a flag to indicate its read-only or making this
statement "as->vaddr = vaddr & readable"

As_define_region is just called to fill out segment information like
size and offset. You can ignore the readable/writeable/executable settings.
You should use the TLB dirty bit to make pages from the text segment
read-only.

Post by Paolo P
2. In every context switch it always calls as_activate to invalidate
the TLB. From my understanding, it should be invalidated if a new
process is created from fork, is it not?

Yes, you should definitely adjust that behaviour so that invalidation
only happens when you switch between two different address spaces.
Otherwise your vm statistics will be bloated.

Post by Paolo P
3. Im confused about how to approach the on-demand loading. In
loadelf, it uses load_segment to load all the pages from the segment
in memory. I assume that I have to use alloc_kpages to allocate a page
but I dont know how to approach two things below without using
load_segment
"Load the page, using information from the program’s ELF file to do so"
and
"Update OS/161’s information about this address space."
I appreciate the help in answering my questions

The modifications to load_elf can be minimal. You should comment out the
load_segment call and replace it with a call to your own function which
simply saves the sizes and offsets somewhere for later use. You should
also save the vnode of the file.
-Alex

[cs350]

I think you can do fork in several ways. One way is to do the
following.

For each stack page of the parent, allocate a new frame, copy the contents
of the stack page into it, and add a corresponding entry to the child's
page table.

When the child eventually runs it will call as_activate. Since the address
spaces are actually different entities, you should invalidate the TLB.

As the child process executes, it will generate TLB faults which will
either involve the stack segment or one of the other two segments. In the
first case, you just load the appropriate translation into the TLB; in the
second case, you go through the entire process of on-demand loading as if
the page was requested for the first time ever.

This will work, as long as the parent never writes to its data pages. This
is a fair assumption for os161, because allowing processes to write to
nonstack pages would mean that you can't free their allocated frames
without backing them up in some sort of a swap file. (And implementing the
swap file has never been a required part of the assignment.)

-Alex

With regards to the TLB Invalidation - it was mentioned earlier that the TLB
should only be invalidated when switching between two address spaces.
However, I'm still unclear whether we should invalidate the TLB on fork.
The answer below states: "Yes, you should definitely adjust that behaviour so
that invalidation only happens when you switch between two different address
spaces."
In other words - that's on every context switch, including on fork, is it
not? Otherwise, if we don't invalidate the TLB on fork, does this mean we are
not switching between two different address spaces when forking a new thread?

Post by cs350

Post by Paolo P
1. So to make text-segment read-only don't I have to achieve that
through as_define_region. though I don't know I can approach this
other than make a flag to indicate its read-only or making this
statement "as->vaddr = vaddr & readable"

As_define_region is just called to fill out segment information like
size and offset. You can ignore the readable/writeable/executable settings.
You should use the TLB dirty bit to make pages from the text segment
read-only.

Post by Paolo P
2. In every context switch it always calls as_activate to invalidate
the TLB. From my understanding, it should be invalidated if a new
process is created from fork, is it not?

Yes, you should definitely adjust that behaviour so that invalidation
only happens when you switch between two different address spaces.
Otherwise your vm statistics will be bloated.

Post by Paolo P
3. Im confused about how to approach the on-demand loading. In
loadelf, it uses load_segment to load all the pages from the segment
in memory. I assume that I have to use alloc_kpages to allocate a page
but I dont know how to approach two things below without using
load_segment
"Load the page, using information from the program’s ELF file to do so"
and
"Update OS/161’s information about this address space."
I appreciate the help in answering my questions

The modifications to load_elf can be minimal. You should comment out the
load_segment call and replace it with a call to your own function which
simply saves the sizes and offsets somewhere for later use. You should
also save the vnode of the file.
-Alex

[cs350]

Come to think about it, you should invalidate simply because the child is
going to use an entirely different set of physical frames. So, the
physical part of the address translation in the parent's TLB/page table
will be wrong for the child.

-Alex