In a Computer architecture book, I studied that Pentium IV has 64 bits bus width and addressable memory of 64 gigabytes. Does it mean that a computer running Pentium IV can support 64GB RAM, if supported by the OS?
This is so-called Physical Address Extension, which was supported by both Intel and AMD processors. Yes, with proper OS support 64Gb of RAM could be addressed. PLease read https://en.wikipedia.org/wiki/Physical_Address_Extension for more information
Related
Is there any data structures of bios or any thing in CMOS to tell about cpu vendor and it's version. I can know about how many processor in system by bios mulitiprocessor specification struct in bios ram area that bios created but what about cpu vendor name and it's version
I recently started working on my own operating system. I am following jsandler18‘s awesome tutorial and making changes as I go to allow it to run on the raspberry pi 4.
Sadly, jsandler18 stopped updating the tutorial before he had finished the page on virtual memory. I read through some other sources, and found a little problem: The ARM l1 address translation table divides the computers RAM into 1-MB blocks. The problem here is that it only allows up to 4096 entries, or 4GB of virtual ram.
Is there some way I can use the ARM MMU to translate more than 4GB of virtual memory?
The tutorial being referenced appears to be executing in ARMV7, which can be thought of as 32-bit ARM. This is roughly equivalent to running in 32-bit PAE mode in X86. Thus using this example it is not possible to to use more that 4GB of virtual memory.
ARMV8 (or AARCH64) supports 64-bit virtual addresses, and would allow mapping more that 4GB of virtual memory.
Switching into ARMV8 is done by switching Exception levels, which are usually denoted as EL0, EL1, EL2 and EL3. The one challenge you could run into is that once you enter AARCH32 mode, you can not go to a lower exception level and switch to AARCH64. For example going from EL1 64-bit -> EL0 32-bit is supported, but going EL1 32-bit -> EL0 64-bit is not. This could pose a challenge if the firmware handing execution off to your OS is in AARCH32 mode.
I am using qemu on Fedora and I find that qemu does not support multi-core. When I use the parameter smp and set cores=2, it will tell me that:
mu-system-riscv: Number of SMP CPUs requested (2) exceeds max CPUs supported by machine 'riscv'
In general, QEMU can support multicore guests, yes. However the number of cores supported depends on the particular board (machine) model you're using. The error message is telling you that the 'riscv' machine you've asked for only supports one CPU.
(In TCG emulation at the moment multicore guests won't be any faster than a single core guest because we don't use all the host cores; this should change in QEMU 2.9 for at least some host/guest combinations when multithreaded TCG support lands. KVM supports multicore guests with no problems.)
I'm currently using a combination of qemu-kvm, libvirtd, and virt-manager to host some virtual RHEL 6 machines. When I go ahead and attempt to bump the ram usage up above 4gb, the machines fail to start. What would even be the cause of this? Any information is helpful.
I'm running a 10 core, 3GHz Xeon processor, with 64 GB of ram.
as here mention, mongodb has limitation of datasize to 2GB in 32-bit machine with one single mongod instance. But I wonder 32-bit machine has 4GB addressable space in theory, and mongod can use this 4GB instead of 2GB for virtual memory usage. So why the answer is 2GB, not 4GB?
4Gb of addressable space is not the same as the memory space available for memory-mapped files opened by user applications. Some of the addressable space is reserved for the O/S kernel and memory-mapped devices such as video cards.
For example, 32-bit Windows limits user mode (and thus memory-mapped files) to ~2Gb RAM and total system RAM to ~3.5Gb.
For more reading, see:
Coding Horror: Dude, Where's My 4 Gigabytes of RAM?
MSDN: Managing Memory-Mapped Files
MSDN: Memory-Mapped Files
The majority of modern desktop and server environments starting moving to 64-bit almost a decade ago (see 64-bit operating system timeline on Wikipedia) so this isn't a limit that practically affects deployment.
You would only want to use 32-bit MongoDB in a development environment with limited data.
32-bit MongoDB processes are limited to about 2 gb of data. This has come as a surprise to a lot of people who are used to not having to worry about that. The reason for this is that the MongoDB storage engine uses memory-mapped files for performance.
By not supporting more than 2gb on 32-bit, we’ve been able to keep our code much simpler and cleaner. This greatly reduces the number of bugs, and reduces the time that we need to release a 1.0 product.
http://blog.mongodb.org/post/137788967/32-bit-limitations