On 18.02.2011 21:53, Stan Hoeppner wrote:
> Fist, sorry for the length. I can tend to get windy talking shop. :)
> Andrew Klaassen put forth on 2/18/2011 2:31 PM:
> > It's IBM and LSI gear, so I'm crossing my fingers that a Linux install
> > will be relatively painless.
> Ahh, good. At least, so far it seems so. ;)
> > I thought that the filesystem block size was still limited to the kernel
> > page size, which is 4K on x86 systems.
> > http://oss.sgi.com/projects/xfs/
> > "The maximum filesystem block size is the page size of the kernel, which
> > is 4K on x86 architecture."
> > Is this no longer true? It would be awesome news if it wasn't.
> My mistake. It would appear you are limited to the page size, which, as
> I mentioned, is still 8 KiB for most distros.
You confuse that with STACK-size.
The page-size is, and has always been, 4 KiB (on X86).
The only exception are the Huge-Pages and while i 'grep'ped for
Huge-pages i found this nice little paragraph in:
Documentation/vm/hugetlbpage.txt (Current git version on it's way to 2.6.38)
- snip -
The intent of this file is to give a brief summary of hugetlbpage support in
the Linux kernel. This support is built on top of multiple page size support
that is provided by most modern architectures. For example, i386
architecture supports 4K and 4M (2M in PAE mode) page sizes, ia64
architecture supports multiple page sizes 4K, 8K, 64K, 256K, 1M, 4M, 16M,
256M and ppc64 supports 4K and 16M. A TLB is a cache of virtual-to-physical
translations. Typically this is a very scarce resource on processor.
Operating systems try to make best use of limited number of TLB resources.
This optimization is more critical now as bigger and bigger physical memories
(several GBs) are more readily available.
- snip -
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.