Date: Fri, 1 Aug 1997 17:42:48 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: davem@jenolan.rutgers.edu (David S. Miller) Cc: toor@dyson.iquest.net, Shimon@i-connect.net, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: Kernel howto, Second Request Message-ID: <199708012242.RAA06093@dyson.iquest.net> In-Reply-To: <199708012150.RAA03675@jenolan.rutgers.edu> from "David S. Miller" at "Aug 1, 97 05:50:03 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> From: "John S. Dyson" <toor@dyson.iquest.net> > Date: Fri, 1 Aug 1997 16:18:33 -0500 (EST) > > Unlike certain (broken) systems, FreeBSD doesn't map all of phys > memory by default. This of course, saves address space for user > processes, and keeps physical memory size from being constrained by > kernel space limitations. > > Yes, but please do not ignore the fact that on modern architectures > (read as: 64-bit) it lacks any these limitations. (for example, on > the UltraSparc under Linux, the full 64-bit virtual address space is > given to the user, and arbitrarily large physical memory > configurations are supported, all this is done at zero cost, and it's > possible to be zero cost because of this "broken" system's design). > Not to mention the fact that in many cases it also makes SMP cheaper > (Linux only performs tlb flush cross calls during swapping, ptrace(), > and for user threads). > The problem is that we are getting questions about large systems now, and limiting phys mem is not an option for us on the PPro. Also, in FreeBSD if you want a mapping to stay around, you can leave it there. (I didn't realize that Linux mapped all of memory anyway, or does it?) I agree that on some architectures mapping all of memory into the kernel is almost free. On other architectures you don't have a choice, and on an X86 it is likely not needed and wasteful. Note that just because of a kernel mapping change it doesn't mean that a TLB flush is needed on ALL processors in every circumstance -- we currently do so too often, but it is only a matter of convienience (read laziness) right now. I have been working/studying the issue of more intelligent (and deferred) shootdowns, and will have some solutions soon, not be so lazy. Yep, for 64Bit architectures, it is probably okay to map all of physical memory -- but the generic kernel depending on it is a mistake (IMO.) There will be 32Bit machines in the future, where it can be advantageous to avoid mapping physical memory. The FreeBSD kernel structure as it is today can do with or without mapping physical memory, just as it can do with or without having the user process mapped when executing in the kernel. On PPros it appears that it is becoming a limitation in certain applications that I am supporting to restrict the physical memory to 1GByte or under -- and FreeBSD is even "limited" to approx 3GBytes (on a PPro.) All this said, I don't really know what Linux does, and that is likely a subject for a Linux mailing list or private email. :-). John dyson@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708012242.RAA06093>