General protection in 64bit mode (Intel)

[nulik]

Hi,
I would like to know if it is possible to achieve general protection (like SIGSEGV interrupt for example) on intel architecture when the processor is in 64 bit mode, with absolute addressing mode (without using paging mechanism enabled).
I have been reading the manuals and Intel Developers 3a volume says that the processor does not perform any limit checking on DS or CS register in 64bit mode (page 5-7)
As I understand Linux kernel uses Virtual Memory and if you use paging mechanism you can easily check limits with page fault interrupt. But in my case, I will not be using virtual memory, I will be using real addressing. Then how would I perform the limit check for processes in userland?

Will appreciate any ideas or pointers to the docs.
Nulik

[gerryg400]

You can't enter long mode without enabling paging. So therefore you can use the same mechanism Linux uses.

[Velko]

First of all: You CAN NOT use processor in 64-bit mode without paging.

[nulik]

You can't enter long mode without enabling paging. So therefore you can use the same mechanism Linux uses.

but I don't need it. Paging wastes a lot of cpu cycles for address translation. Why would I use this thing if I have a lot of memory? And also I don't allocate large memory blocks, so contiguous allocation is not a problem for my OS.

I need to avoid paging somehow , but be able to use 64 bit capabilities of the processor.

[bluemoon]

but I don't need it. Paging wastes a lot of cpu cycles for address translation.

Any benchmark?

Paging, when used properly, avoid memory fragmentation, provide consistent address spaces, and enable you to adopt better algorithm like page sharing, copy-on-write, swap, etc.
These features and performance boost should be considered.

However, a poorly written software may keep generating TLB miss, but that's the software problem to be fixed, not paging.

[rdos]

64-bit long mode has 4 (!) paging levels, and that this would not degrade performance could not be true. At the least, it wastes a lot of silicon if it manages to keep performance somewhat similar to a non-paged design. Of course, we cannot test this as it is not possible to turn off paging in long-mode.

Paging in 32-bit also has a performance penalty. It was quite considerable on the first CPUs like 386 CPUs. But it only contains 2 levels, not 4.

[Combuster]

64-bit long mode has 4 (!) paging levels, and that this would not degrade performance could not be true.

It has been experimentally established that 64-bit mode (paging required) is faster than 32-bit mode (with paging).

[rdos]

64-bit long mode has 4 (!) paging levels, and that this would not degrade performance could not be true.

It has been experimentally established that 64-bit mode (paging required) is faster than 32-bit mode (with paging).

If it has, it is not because of a faster design, but that the CPU chips have been made in such a way that optimizes 64-bit mode over 32-bit mode. Besides, with which CPUs was this estabilshed so I can avoid them in the future?

Does this mean that x64 is just another Itanium-like design that has not implemented x86 properly?

[Combuster]

History shows there's no way your brain would be able to deal with the explanation, so I'm not going to answer and derail the thread in your honour. I hope the OP did get the point first time around.

[Casm]

but I don't need it. Paging wastes a lot of cpu cycles for address translation.

Whether you need it or not, AMD decided to disable segmentation in 64 bit mode, which would be the only other way of implementing memory protection.

It should be at least a little while before anybody needs more than the 64Gb they can get with physical address extension in 32 bit mode.

[Casm]

64-bit long mode has 4 (!) paging levels

The days of 4kb pages have got to be numbered, otherwise we will end up with twenty levels of page tables. Maybe I exaggerate a bit.

[nulik]

Any benchmark?

Yes! I did not do it myself but here is a presentation claiming that:

"Even assuming 100% HIT rate in Main Memory the penalty of using virtual memory is 2X"
http://6004.csail.mit.edu/Spring98/Lect ... sld013.htm

MIT teachers must know something aren't they?

Paging, when used properly, avoid memory fragmentation, provide consistent address spaces, and enable you to adopt better algorithm like page sharing, copy-on-write, swap, etc.
These features and performance boost should be considered.

However, a poorly written software may keep generating TLB miss, but that's the software problem to be fixed, not paging.

Well, I don't need this really. In my OS you will have a memory partition table (just like disks do), where each application will have a fixed code and data size. So I won't have a problem with fragmentation.

Just think about it, TLB only can cache about 1K of pages, how much cache is this compared to a physical RAM of a 32GB machine? And on every TLB miss, you have to read DRAM and scan for pages, the speed of DRAM is about 200 clock cycles because of inefficiency of dynamic ram design. If theoretically paging is a waste of resources, themn practically it will certainly be, you won't even need a proof.

So, back to my question...
If paging can't be disabled, I could enable the largest page size and every process will have to have a minimum of MAX_PAGE_SIZE size data segment .... crappy solution but what can you do?

[Combuster]

MIT teachers must know something aren't they?

They probably did, 13 years ago.

In my OS you will have a memory partition table (just like disks do), where each application will have a fixed code and data size.

That's probably your real problem. A program's code size will be fixed, but it's memory size will change depending on what open files and tasks you have. Basically, your assumption only holds for simple embedded devices, it's not workable on any desktop/server configuration.

[gerryg400]

Yes! I did not do it myself but here is a presentation claiming that:

"Even assuming 100% HIT rate in Main Memory the penalty of using virtual memory is 2X"
http://6004.csail.mit.edu/Spring98/Lect ... sld013.htm

MIT teachers must know something aren't they?

That presentation looks like complete guesswork to me. It doesn't describe how the time measurements were made nor does it say which particular microprocessors were benchmarked. Also as Combuster pointed out is completely out of date. 13 years is an eternity.

Just think about it, TLB only can cache about 1K of pages, how much cache is this compared to a physical RAM of a 32GB machine? And on every TLB miss, you have to read DRAM and scan for pages, the speed of DRAM is about 200 clock cycles because of inefficiency of dynamic ram design. If theoretically paging is a waste of resources, themn practically it will certainly be, you won't even need a proof.

You're guessing. But if you're worried stick with 32bit and don't enable paging or switch chip vendors.

.... crappy solution but what can you do?

Read the Intel documentation, including the application notes, follow all the performance hints that they give. There's a lot of information around about how to optimise for their chips.

[rdos]

Yes! I did not do it myself but here is a presentation claiming that:

"Even assuming 100% HIT rate in Main Memory the penalty of using virtual memory is 2X"
http://6004.csail.mit.edu/Spring98/Lect ... sld013.htm

MIT teachers must know something aren't they?

That presentation looks like complete guesswork to me. It doesn't describe how the time measurements were made nor does it say which particular microprocessors were benchmarked. Also as Combuster pointed out is completely out of date. 13 years is an eternity.

Even if it were 30 years old it would still show the obvious that a system without paging is faster than a system with paging. I don't understand how anybody can argue otherwise. And a system that uses 4 levels of paging and has double the size of the page-entries MUST be slower than a system with 2 levels. That's common sense. If that does not hold, chip-vendors are favoring 64-bit over 32-bit in their silicon-solutions in order to make them move to 64-bit.