As far as I can tell, the page size in the kernel is determined when the source files are compiled using CONFIG_PAGE_SIZE_4KB, CONFIG_PAGE_SIZE_8KB ect options. I don’t think you can switch on the fly. I found a pointer to a program that might let you change the page file size for applications at:
The bottom line is, what type of problem are you trying to solve here by changing the kernel page size? Linux too slow on a server or something like that?
For anyone that wants to check their kernel page size run the terminal command:
On 04/13/2010 08:46 PM, jdmcdaniel3 wrote:
>
> As far as I can tell, the page size in the kernel is determined when the
> source files are compiled using CONFIG_PAGE_SIZE_4KB,
> CONFIG_PAGE_SIZE_8KB ect options. I don’t think you can switch on the
> fly. I found a pointer to a program that might let you change the page
> file size for applications at:
>
> ‘libhugetlbfs | Get libhugetlbfs at SourceForge.net’
> (http://sourceforge.net/projects/libhugetlbfs/)
>
> The bottom line is, what type of problem are you trying to solve here
> by changing the kernel page size? Linux too slow on a server or
> something like that?
>
> For anyone that wants to check their kernel page size run the terminal
> command:
>
> getconf PAGESIZE
You are correct that the PAGESIZE is set at kernel compile time.
Furthermore, that selection is only valid for i386 hardware. If you run
a 64-bit system or any other architecture, the page size is 4K and
cannot be changed.
Wow you are second person that I answered in last 24 hours about blocksize confusion.
Linux can have sector sizes of 512bytes, 1024bytes, 2048bytes, 4096bytes, or 8192bytes ONLY! 4096bytes is the default. If you increase as you suggest to a 64kbyte size then every file on the device would occupy at least 64k of space. If you have a script file that is only say 3 lines at maybe a total of 200bytes it would take up 64k of space instead of the default 4k of space. With Linux having so many tiny files you would need a huge HDD just to have a minimal system. Files that are larger as in a picture of say 250kb or a database of say 64Mb would use multiple sectors with only the last one containing unused space.
Therefore the system becomes more efficient with a 4k sector size than a 64k sector size. Ideally, many people start talking about blocksize when they really mean sector size used with files or partition size when dealing with filesystems.
You are right!
But the I/O to underlaying device structure; such as LVM.
Must be clever enough to bundle many filesystem blocks into bigger I/O blocks for performance improvement.
See “vmo” on AIX.
That is the reason for why we are looking for bigger blocks on the filesystem layer.
You are barking up the wrong tree! What you want as described in AIX vio ioo is a read ahead cache system to improve speed of transfers when doing sequential reads.
On 04/16/2010 08:36 AM, techwiz03 wrote:
>
> daleto;2153469 Wrote:
>> You are right!
>> But the I/O to underlaying device structure; such as LVM.
>> Must be clever enough to bundle many filesystem blocks into bigger I/O
>> blocks for performance improvement.
>>
>> See “vmo” on AIX.
>>
>> That is the reason for why we are looking for bigger blocks on the
>> filesystem layer.
>>
>> //Tomas
>
> You are barking up the wrong tree! What you want as described in AIX
> vio ioo is a read ahead cache system to improve speed of transfers when
> doing sequential reads.
>
> maybe someone else has some alternative for you.
To answer the original question, you cannot set the PAGESIZE to
arbitrary sizes. It is fixed for all architectures except i386 where it
may be 4K or 8K. Even there 4K is recommended. The option was allowed
when using Windows drivers with ndiswrapper as they put a lot of stuff
on the stack and would get overflows.
You are somewhat correct, but there are definite situations in which having a larger block size is extremely advantageous. I agree that on the default root filesystem, this is a waste of space. That does not mean that this holds true for all scenarios. Take a filesystem that is only hosting a relational database system, like Oracle, MySQL, Postgres, etc. On such a filesystem, you know that your database files are going to occupy more than 64KB (or 128KB or 256KB), and performance may improved with increased block size, since you know that, not only are you storing that much information, you’re going to be reading and writing information in chunks that are at least that large.
I’m not sure about your point over the confusion of sector vs. block size. If there is confusion, it’s because the folks who wrote filesystem utilities have created it. In most filesystem format commands (mkfs.xfs, for example), there is an option to set block size. Not sector size, block size. As you state, this is the minimum amount of space that will be consumed by a file when written to that filesystem, and, as you state, that may be less efficient - but, again, that depends on how you’re using that filesystem.
There are also other things to consider, like the page size of the kernel. If your filesystem can format with a block size larger than the page size, is there really any performance benefit? Maybe this is why Linux pegs max block size to page size - because it doesn’t matter. This isn’t necessarily true of all operating systems and filesystems, though, and performance gains have been realized on filesystems formatted with larger block sizes when it is known that the vast majority of files on those systems will be large files.