64bit OS development Brainstorm Thread

[pskyboy]

Hey guys

I just thought i would throw this thread up as a bit of an area for people to toss around ideas for OS development on newer architectures especially 64bit ones. It also gives me a place to throw out some of my ideas to see what people think of them. Also i welcome any questions about why im doing it for 64bit and about the 64bit architecture (hopefully i will be able to answer them).

Anyway let me give a quick intro to my OS, the 64bit platform allows me to generally have more memory that is one of the biggest advantages. The other is a faster OS as at least on Hammer i have an extra 8 registers over the Athlon Pentium etc.

the first bit of my OS is that i have expanded the App address space from 4Gb demand paged to 16Gb demand paged. I could have up to 256Tb but the page tables would be ridiculous, there bad enough as it is on 16Gb and i will probably have to use inverted page tables.

Anyway any comments, ideas or critisms are welcome to make me think about my implementation.

Peter

[jrfritz]

Page tables ... on 16GB is bad? Maybe time for some new architecturing!

[Tim]

Current AMD X86-64 implementations don't let you use the full 64-bit address space, because of the nightmare of page tables. They only let you use a few gigabytes (16GB? can't remember) and they sign-extend addresses. The result is that you get something like this:
[table][tr][td]0GB[/td][td]Application memory[/td][/tr]
[tr][td][/td][td](invalid)[/td][/tr]
[tr][td]256TB[/td][td]Kernel memory[/td][/tr][/table]
This way, current X86-64 operating systems will still be compatible as newer chips with bigger address spaces come out.

I got the AMD information from www.sandpile.org. AMD have manuals available from their site, although last time I looked they were print-only and they wouldn't ship outside North America... grr... >:(

I have no idea how Intel IA-64 works in this respect...

[pskyboy]

I have a copy of all the AMD manuals in pdf format. You can download them from AMD's site. And they let you have a 48bit virtual address space at the moment which allows 256Tb which is insane and the page tables are also hugh which is why i decided to restrict the address space to 16Gb. I could give a full 256Tb address space using inverted page tables and i am considering this but inverted page tables are slow and more coding is needed to get them working.

As for IA-64 i have only read a bit about it and am not sure what its memory managment is like but i know it is a VLIW processor and can process multiple instructions and once. It is basically what encouraged the Hyperthreading in the P4's except its done much better in the itaniums and the architectures designed for massive parrellel processing.

Peter

[Curufir]

Hmm, with an address space that large then you could get rid of the filesystem altogether and use media as plain memory.

Of course you'd have to figure out some method of keeping running tasks in the physical RAM with everything else masquerading as RAM on the media, but it would certainly save you in terms of filesystem translation.

Doesn't help until you figure out how to keep the memory assigned to page directories/tables to a minimum though.

[pskyboy]

Hmm, thats an interesting idea actually. It may well be worth investigating. It would define a whole new way of accessing files. It could be the next big way of doing things in computers and my motto is nothing ventured nothing gained.

Im also trying to make my OS a base of new ideas and ways of doing things that could potentially make computers easier to use.

Peter

[pskyboy]

Damn, i really do like that idea the more i think about it the more i like it. Im really annoyed i didn't think of that,

Peter

[pskyboy]

Me again, Hmm maybe i need to modify threads next time.

I just had an idea about that, it wouldn't be that big a problem as a file that is accesed could be mapped into the page tables but only actually have a page loaded in when that page is actually accessed. The other thing is as soon as pages need to be chucked out if they haven't been edited its easy and they can go first and if they have it just updates the page in the file.

Peter

[Tim]

[attachment deleted by admin]

[Curufir]

That seems to be pretty much what I was talking about. I've actually been considering this one for some time, mostly in relation to my own project, but I didn't have the address space large enough to pull it off without some trickery.

Here is the non-large address space idea I had. If you use the hard disk as just a memory area, then you can use a driver something like EMMS does with DOS. EMMS(Think that's the right one, could be wrong) fetches data from above the 1mb region down into the 1mb region for execution. The driver here would be fetching from the hardrive/floppy down into the physical RAM. Same principle, just needs careful management because of the latency pulling things off the hardrive/floppy.

Now so long as you maintain the page directories/tables of each process on disk then you could do precisely the same thing even if you don't have a big enough address space to reach the whole disk. So effectively the page directory/table entries replace the inodes, without any space increase.

Of course this environment is totally persistent, so an error in maintaining the disk structure would be a killer, but with something similar to an LFS filesystem you should be able to get away with it.

Now, at this point all you have is a set of processes running in memory, you don't have any means to load a new one. That problem gets solved by having what would conventionally be called files stored in the data space of a seperate 'file' server process. A request for a 'file' just means copying the relevant page tables of the 'file' into RAM, the memory manager will take care of the rest of it. To put it more simply, every application starts its life as a thread of the file server, with unix style copy on write for the data section of the application. In my small address space scheme this means having to run more than one 'file' server to cover large disks.

I hope I've demonstrate how this concept gets fairly involved fairly quickly. There are many difficulties to overcome, which is why my design is still in flux.

[jrfritz]

pskyboy, post more info on x86-64 to Curufir and maybe he'll have more ideas

[pskyboy]

I thought about this somemore and i was thinking you would still need some kind of file system to identify where the files are, this isn't a problem in its self obviously.

What i was thinking was to have my file system mapped from say 8 or 16Gb up to 256Tb leaving the bottom 8 or 16Gb for the current running process and OS stuff. I would then essentially have the area from 16Gb up to 256Tb mapped into every process. I could then have another thread which looked after File Managment.

Then when an application opens a file the File Managment thread could be called which would search the FAT essentially find the position of the requested file and then hand the pointer back to the App. Then all the app has to do is access that position as data and the files there.

The other way to do it would be to have a completly seperate Virtual Address space for the Files and then when one is requested locate it and map it in to the App requestings address space. This would be very similar to what happens now except the file system would be mapped into memory.

Peter

[pskyboy]

Looks like a neat feature of teh way memory mapping works on x86-64 means i can map a 4Gb range of memory for the OS. This will also mean i can remap it into other processes with extreme ease by simply chaging a page directory entry and will mean i can map it anywhere from 0-256Tb.

The only problem comes about in telling the Apps where the Kernel is i could pass it as a parameter to main when i start an App which is my favorite at the moment. Or i could use the standard approach which is to have it at a set position but that would mean i can not put it anywhere i want. I guess the advantage of having it at a fixed address is speed as address calculations would be able to be resolved at compile time.

What do people think would be best as the overhead for doing address calculation would be slight. I could even set one of the segment registers to point to the kernel space.

Peter

[pskyboy]

Ive just had another idea as well which is x86-64 allows Monolithic and Micro Kernels to be combined in a way. What i plan to do is give each driver a 4Gb address space to function in. But this 4Gb block can be mapped into the 256Tb address space allowing for a driver which can't crash the whole OS as i will have guard pages on the 4Gb block and will stop it if it tries to access outside that range. That way i have the stability of a micro kernel with the speed of a monolithic as i don't need to do a task switch to use the drivers.

Peter

[K.J.]

You can download PDFs of the AMD x86-64 books now:
http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html

I'll have to read through this entire thread tomorrow and see if I have anything else to toss in.

K.J.