Andrew Brown has committed changes to -current implementing a new ‘topdown’ uvm. With these changes, the areas for heap growth and mmap(2)‘ed allocations, which used to
be separate, are now one and the same, allowing either one to grow much larger than before. As an example, on i386 it is now possible to mmap(2) over 2GB of
memory.Furthermore, the work leading up to this has already dramatically reduced the number of entries in the kernel’s map. At the moment, this option is available for the i386, macppc, prep and the PowerPC OEA based ports, but
particularly ports with small amounts of virtual memory such as the acorn26 benefit from these changes.
For more details, please see the thread starting with Andrew’s posting to the
current-users MailingList.
that the “Understading the Linux kernel” book I just bought is outdated….
Well, its always nice to see linux and other open source projects making progres..
Kudos to Andrew Brown.
Although it’s a wonderful resource, it’s already kinda outdated, as it applies to kernel 2.2. Many things (VM, task queue mechanism, I/O layer, etc) have changed. However, there is a project to better document the new Linux VM. http://www.csn.ul.ie/~mel/projects/vm/ At the moment it applies to the 2.4 kernel, but as soon as the 2.5 VM stabilizes, it’ll be updated to that as well.
Linux =! NetBSD
NetBSD =! Linux
.. focused on linux they cannot admit that others can do breakthrough!!!
The NetBSD developers really need to focus on getting SMP to play nice with the new kernel threading.
I installed 1.6 and then upgraded to -CURRENT. Everything worked great till I started running apps compiled against the new threading libraries. Unfortunately, running any of them would cause my machine to lock solid.
Now, I realize that’s what I get for running -CURRENT, but perhaps it’s time to stabilize things a little before adding a new UVM 🙂
Adam
But is NetBSD ready for the desktop? Even with the new UVM, I think not. Even Eugenia agrees, I mean it doesn’t even have a start button. I’ll stick to Windows 98.
is already at 4GB memory support 8) will get better for 64-bit machines.
is already at 4GB memory support 8) will get better for 64-bit machines.
Well, actually, Linux is already at much more than that (eg. the 512GiB in the Alticx). 4GiB is the practical limit for most 32bit machines, but Intel’s horrible PAE extensions let the OS (eg. Windows NT/2k, Linux) use up to 64GiB on certain x86 boxes.
The story isn’t really a breakthrough, but is more a part of Net being brought up to modern standards.
UVM is a really nifty virtual memory manager that is rather different from traditional VMs. Whereas most of the focus of current VM research, in FreeBSD and Linux, have been on better paging performance, UVM was designed with an eye to advanced memory sharing schemes. It has features like page transfer, page loanout, and has some interesting data structures to fix complexities that arise in the traditional BSD VMs under heavy sharing. It’s *very* well documented. http://www.ccrc.wustl.edu/pub/chuck/tech/uvm/
The website has some FAQs, some shorter papers, and Cranor’s well written dissertation on the system. It’s a long read (270 pages) but you’ll know more than you ever wanted to about virtual memory.
Well, it depends. NetBSD has KDE and GNOME, too.
OTOH, NetBSD dosn’t have other features important to some people.
IMHO not even Linux is ready for Joe’s desktop (again: just MHO).
It depends on what you expect from your OS.
Thats an ill-formed question. The focus is on the kernel, system and user utilities, etc. The classic CLI UNIX portion which is close to the hardware and low level fundamentals.
Their focus isn’t with any GUIs like KDE, GNOME or a windowing framework whose purpose is to be amenable to human<->computer interaction, which is what the “desktop” metaphor is associated with.
Asking that is sort of like asking if a car engine is ready to drive by itself. It’s merely a very important component.
Never ever noticed the NetBSD….Ok, that will teach me not to comment anything at 1. am in the morning.
*ducks and hides in a corner*
can a package (program) run unchanged on most/all of netbsd’s ports? or do they have to A. recompile the program or B. completely port to each platform?
I was just wondering how they support all the (50ish) platforms the netBSD runs on. Everytime I think of that, I am impressed, good work netBSD hackers!
as its an os not an “emulation engine”…. although it does have quite a nice selection of emulators available from what ive seen
I’m quite sure “Desktop Evaluator”s post was meant to be a joke, a funny one at that too.
Too bad no one has explained how the “topdown” UVM differs from the previous UVM algorithm..
Here is a more detailed description of the topdown UVM algorithm:
http://mail-index.netbsd.org/source-changes/2003/02/21/0001.html
Introduce “top down” memory management for mmap()ed allocations. This
means that the dynamic linker gets mapped in at the top of available
user virtual memory (typically just below the stack), shared libraries
get mapped downwards from that point, and calls to mmap() that don’t
specify a preferred address will get mapped in below those.
This means that the heap and the mmap()ed allocations will grow
towards each other, allowing one or the other to grow larger than
before. Previously, the heap was limited to MAXDSIZ by the placement
of the dynamic linker (and the process’s rlimits) and the space
available to mmap was hobbled by this reservation.