Does every process have its own page table? - memory-management

Does every process have its own page table or does it simply add it's page entries into one big page table?

Yes every process has its own pagetables. They might be shared with the parent process(copy on write) or with other processes(shared memory). But in general every process has its own.

Yes, unless you use an inverted page table see this answer. Because an inverted page table is global, each entry must also contain which process it belongs to.

Related

In OSes that use page tables, are page tables ever empty?

In studying shadow paging mechanisms, I learned of a case where a shadow page table starts out empty and only gets filled in as the guest VM accesses memory. It got me thinking about traditional page tables. When the OS is running and a page table becomes empty (perhaps when the page table's process terminates), I would think that page table gets released as a free page of memory.
Is there ever a case where an empty page table or even empty page directory table can exist during normal operations? Three cases I can think of are:
When the OS boots - but my understanding is that modern OSes like Linux start in real mode and then switch to paging mode, during which I would imagine process 1 gets its own page table with kernel mappings among other things. Is this correct?
If the last valid entry in a page table is then unmapped or swapped out - but I've also read that invalid entries could be used to store swap addresses, so not sure exactly.
When a new process is spawned - although I think similar to 1), a new process is started with kernel mappings and linked library mappings, so it would already have a small page table upon starting.
UPDATE: I learned that even in the shadow page table where it starts out "empty", it still has some mappings to hypervisor memory, so even then the page tables are not truly empty.
There's no point in having an empty page table, so I'll say no.
If you mean one particular table, then leaving it empty is a waste of memory. If you have an empty page table, you can free it, and in the place that pointed to the page table, you tell the CPU that there is no page table. For example, if a level-1 page table is empty, instead of pointing to it in the level-2 page table, you can put an entry in the level-2 page table which says "there is no level-1 page table for this address".
If you mean the entire set of page tables - so are there no pages at all - the CPU can't run any instructions without page tables (unless paging is turned off) so that's still a no. The CPU would triple-fault (x86) and reboot.

Does page table changes with context switch?

Suppose, the page table changes with each processes then we don't require TLB and memory for page table. We can implement it with some reasonable number of registers. But the galvin book says(not precisely but my interpretation) we have an entry in page table all pages and we have separate table for each processes so we are using pointer to refer a particular table.
Am I correct(understanding from the book)?
If then what is the need to change the page table for each context switch?
if we are arguing that we can use one page table for whole system then simple answer to this question is that using page table/process provides more security by providing memory isolation among processes running on same system. each process has its own page table means it can not interfere with other processes memory. page table management can not be achieved through registers due to size and number of page tables. suppose you want to have extra registers to store active page tables still you will need memory to store back inactive page tables this is equally expensive method(for your first line). I suggest you to spend some time on understanding of present hardware facilities and OS functionalities then try to come up with innovation in design otherwise you will remain astray from learning.
your Op title ask "does page table changes with context switch" YES page table changes on context switch

Reduce Menu Generation Time

Warning
I wanted to add a disclaimer to warn against this database structure. I would highly advise a more streamlined approach.
My personal preference is to use a hierarchical one or two table structure to store navigation menus. For guidance on erecting a menu from a flat structure, see https://stackoverflow.com/a/444303/1778606
Answer
In my case, the answer was to cache the menu on the client. Read on if you want.
I have a three tier menu that is generated using several queries. In the application I have inherited, there are many user groups. Each user has access to different pages/parts of the web application via user groups. A single user may be in many user groups.
In their menu, each user should only be able to see and access pages their groups have access to. ie. only certain Menu Items, Menu Submenu Sections, and Menu Submenu Section Items should be visible for each user. The pivot tables control visibility and access.
To generate the menu, I need to make several queries. My sample proposed menu design is shown below.
This menu looks drastically different depending on which tier1, tier2, or tier3 items a user has access to.
Would it be appropriate to cache the entire menu in session for each user instead of generating it for each page load? Would this be potentially to much data to cache? My main concern is that it would like cache all three tables (Tier1, Tier2, Tier3) for each active user in session. I need to access the data anyway to see if the user has permissions, but meh!
Are there any architecture designs that would help reduce the number of queries required to generate the menu? (assuming the menu is generated on each page load as normally works as I assumed when I started writing this question)
Is this kind of menu thing normal in applications - we have like 20 groups and users are in anywhere from 2 to all 20? Any advice or comments are welcome.
(I want to minimize page load and processing time.)
Context:
I'm using c#, asp.net mvc3, oracle. Max user base estimated at ~20,000. Max active user base close to 1000. Likely active user base is 100.
At first when a user logs in, then load the permitted menus under the logged in user in cache. Then access the menus/submenus from the cache for that user. when the user logs out then clear the cache. In this scenario each time a new user logs in, cache will only be loaded for that user.
Thanks
Instead of using session to cache this information, you could add something like app fabric or memcached.
This has the advantage of not having to handle session in a load balanced application.
Space should not be much of an issue.
Load the entire menu once for the each user and cache it on the client.
It won't need to be reloaded unless they invalidate the cache (via a reload).
A query will still be needed on each page to validate the user has permissions.
(Answer attempt #2 for my own question)
Heres an option...
Keep the Tier1, Tier2, Tier3 data table in the application data cache
Store the primary keys of the Tier1, Tier2, Tier3 tables in arrays in session for each user, ie. a Tier1Key, Tier2Key, Tier3Key int[].
This should reduce the memory footprint somewhat. There is still going to be a bit of a load generation. You may be able to solve this by using a partial view for the submenu and caching the partial view on the client. (This would require a delayed partial menu load via ajax, which would happen on MenuItem click)
You may need to a query to validate access on each page.
for client caching, see OutputCache Location=Client does not appear to work,
(Answer attempt for my own question)

How Linux Operatin g System maintains Page Table?

Does page table per Process or per System ?. Is KERNEL maintain entire single shared page table for all process ?
Most OS's allocate the page table for each process and store the pointer of the table in the register and include it in the PCB

Referencing object's identity before submitting changes in LINQ

is there a way of knowing ID of identity column of record inserted via InsertOnSubmit beforehand, e.g. before calling datasource's SubmitChanges?
Imagine I'm populating some kind of hierarchy in the database, but I wouldn't want to submit changes on each recursive call of each child node (e.g. if I had Directories table and Files table and am recreating my filesystem structure in the database).
I'd like to do it that way, so I create a Directory object, set its name and attributes,
then InsertOnSubmit it into DataContext.Directories collection, then reference Directory.ID in its child Files. Currently I need to call InsertOnSubmit to insert the 'directory' into the database and the database mapping fills its ID column. But this creates a lot of transactions and accesses to database and I imagine that if I did this inserting in a batch, the performance would be better.
What I'd like to do is to somehow use Directory.ID before commiting changes, create all my File and Directory objects in advance and then do a big submit that puts all stuff into database. I'm also open to solving this problem via a stored procedure, I assume the performance would be even better if all operations would be done directly in the database.
One way to get around this is to not use an identity column. Instead build an IdService that you can use in the code to get a new Id each time a Directory object is created.
You can implement the IdService by having a table that stores the last id used. When the service starts up have it grab that number. The service can then increment away while Directory objects are created and then update the table with the new last id used at the end of the run.
Alternatively, and a bit safer, when the service starts up have it grab the last id used and then update the last id used in the table by adding 1000 (for example). Then let it increment away. If it uses 1000 ids then have it grab the next 1000 and update the last id used table. Worst case is you waste some ids, but if you use a bigint you aren't ever going to care.
Since the Directory id is now controlled in code you can use it with child objects like Files prior to writing to the database.
Simply putting a lock around id acquisition makes this safe to use across multiple threads. I've been using this in a situation like yours. We're generating a ton of objects in memory across multiple threads and saving them in batches.
This blog post will give you a good start on saving batches in Linq to SQL.
Not sure off the top if there is a way to run a straight SQL query in LINQ, but this query will return the current identity value of the specified table.
USE [database];
GO
DBCC CHECKIDENT ("schema.table", NORESEED);
GO

Resources