| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12
<gr0ober> w00t
<gr0ober> yo!
<gr0ober> what's up?
<mur> lamp
<mur> i think
<gr0ober> heh
<gr0ober> whattayaknow... some ****er took my nick
<gr0ober> i lost a "0" to a ****ty "o" :-(
<geist> sup folks
<gr0ober> paging :-)
<gr0ober> thinking about the page fault handler... probably going to use a stack to hand out pages...
<gr0ober> just wondering: stacks won't gimme continious memory... will that become a problem?
<geist> what do you mean?
<geist> they wont grow forever?
<mur> the diapers?
<mur> no, i stopped using them already
<geist> remember, when you start talkinga bout memory and paging, you need to start being more specific, virtual or physical
<gr0ober> physical
<geist> but you're paging
<geist> ify ou're using virtual memory, having contigiuous physical memory doesn't make any difference
<gr0ober> if I need to get continuious physical memory for some reason... dunno if that's actually a prob (i'm thinking dma and ****)
<geist> *with few exceptions
<gr0ober> exactly!
<gr0ober> lol
<geist> dont worry about that right now
<gr0ober> what are those?
<gr0ober> i really don't wanna worry, but...
<geist> very rarely do you actually need contiguous physical memory in a region
<gr0ober> i also dont' wanna write a physical allocer that sux in the future
<geist> you can safely not optimize for allocating contiguous physical runs
<geist> (for the first p*** at least)
<gr0ober> ok, no we have written the contig... word in five different ways lol
<gr0ober> geist, ok... perhaps I can forget about it for now
<geist> by the time you'll need to potentially worry about it, it'll be very advanced and it'll be the least of your worries
<gr0ober> you recommend a simple stack?
<geist> be more specific please
<gr0ober> ok:
<gr0ober> I'm thinking about:
<geist> I dont like answering questions without context because I dont know precisely what I'm answering
<gr0ober> i understand
<geist> and I'd rather not answer at all than answer incorrectly
<gr0ober> 1) Running through avail memory and splitting it up in 4K chunks
<gr0ober> 2) For each chunk, I put the physical address on a stack
<gr0ober> 3) When I call getFreePhysPage(...), then I pop off an address (if it fails, i'll page out, but that's way ahead)
<gr0ober> 4) When releasePage(...) I push the address back on to the stack
<gr0ober> Am I making sense?
<geist> sure
<geist> that makes sense, it's how most systems do it
<gr0ober> pew
<geist> but to be more specific, how are you pushing the address on the stack?
<geist> are you creating a structure with the address in it?
<gr0ober> I was thinking of having a simple array
<gr0ober> and inc/dec a pointer
<geist> array of what?
<gr0ober> proportional to the number of pages in size
<geist> wha? okay now that's just weird
<geist> here's how you should do it (virtuall everyone does it this way)
<gr0ober> array of sizeof(phys_adr)
<geist> create a structure per physical page
<geist> struct phys_page {
<geist> unsigned long paddr;
<geist> struct phys_page *next;
<geist> some other crap here maybe;
<geist> }
<gr0ober> I have such a struct... oh, but no next pointer
<gr0ober> Let me guess:
<gr0ober> The stack is traverersing the linked list?
<geist> bingo
<gr0ober> nice
<geist> the stack is a singly linked list, with a head and tail pointer
<geist> the reason that you want to do it that way will become more obvious later
<geist> since you can use that next pointer for other things
<geist> you can use it to link to the next page in whatever list the page is in at the time
<geist> and the list can be in every vm_object, or every physical queue
<geist> lemme see if I can find it in newos code
<gr0ober> uhm... Is pushing a page back on the "stack" just updating the tail?
<geist> updating the head
<gr0ober> so you pop by going "next" and push by updating...
<gr0ober> head, right
<geist> http://newos.org/WebSVN/filedetails.php?repname=NewOS&path=%2Fnewos%2Finclude%2Fkernel%2Fvm.h&rev=0&sc=0
<geist> see vm_page
<gr0ober> very clever... or obvious perhaps to everybody else :-)
<geist> list_node is just a node in a doubly linked list
<geist> I reuse that structure all over the place
<geist> I should document some of those fields a bit better
<gr0ober> right, so the page can take part in many kinds of lists
<gr0ober> queues, etc, etc
<geist> right, in this particular case it's in 3 different lists
<gr0ober> by means of list_node, you can basically plug it everywhere
<gr0ober> nice
<gr0ober> ref_count is for shared data?
<geist> 1) it's always present in one of many queues: free, cleared, active, inactive, unused, wired
<geist> when you allocate a page you're just moving it from the free or clear queued into the active or wired queue
<geist> the cache_node list entry is a node in a list present in every vm_cache object, which is the base object behind any vm region
<geist> or a memory mapped file, etc
<geist> that was 2)
<geist> 3) it's in a globla hash table keyed by the vm_object it's currently present in, and the offset field, which is the offset into that object
<geist> which is how you'd quickly find it for a page fault, for example
<gr0ober> that was a lot of queues... is it documented what all those mean?
<gr0ober> wired, etc?
<geist> not really, I should document it though
<geist> see the page_state enum?
<geist> that's the different states the page can be in
<geist> most are relatively obvious
<gr0ober> yup
<geist> free means it's up for grabs, clear means it's free but the contents are guaranteed to be zeroed out
<gr0ober> obvious? I was thinking free and non-free :-)
<geist> I have a daemon that continually pulls pages from the free queue, memsets them to zero, and moves them to the clear queue
<gr0ober> hm
<geist> active means the page is in use, and mapped at least in one address space somewhere
<geist> inactive means it's in use, but not actually mapped anywhere
<gr0ober> you mean a thread dedicated to moving pages between queues ?
<geist> busy means IO is currently in progress on that page, and you can't touch it
<geist> yes
<gr0ober> ok
<geist> modified and modified temporary means it's in use and has "dirty" data on it
<geist> unused means you can't touch it. I use that for pages from 640k-1MB
<geist> wired means it's fixed in memory, the kernel is forexample "wired"
<geist> you can't touch it, dont bother
<geist> those states are most important int he case of page replacement
<geist> when deciding what page you can swap out, or which one you can reclaim
<gr0ober> makes sense
<gr0ober> how do you track dirtyness?
<geist> you can ask the mmu for the dirty bit
<geist> I think pretty much all mmus support it
<gr0ober> when do you ask?
<geist> otherwise you'd have to make the page as read-only, and when someone writes to it remember that it's dirty and remap as read/write
<geist> I have a daemon that continually scans through pages tracking their modified status
<geist> and active/inactive, if the free page count is running low
<geist> it's quite complicated
<gr0ober> i'm sure it is
<gr0ober> vm_region is a region within an address space?
<gr0ober> say, stack, data, code?
<gr0ober> or something completely else?
<geist> yes, that's correct
<geist> lemme see if I can draw up a simple diagram
<gr0ober> ok
<geist> ascii diagrams are always a PITA
<gr0ober> yup :-)
<gr0ober> someone ought to write a Powerpoint -> PITA converter
<gr0ober> err, someone ought to write a Powerpoint -> ASCII converter
<Andares> gr0ober, heh, powerpoint features a PITA converter already. :) It's built in!
<gr0ober> lol
<geist> okay, looks something like this
<geist> http://newos.org/vm.txt
<geist> we can revise as we go
Return to osdev
or
Go to some related
logs:
irc iptables settings
ports bf2 router
iris-concerte
fahrenheit in godmode
|
|