Kevin O'Gorman wrote:
> mlw wrote:
> > Many operating systems used a fixed memory block size allocation for
> > their disk cache. They do not allocate a new block for every disk
> > request, they maintain a pool of fixed sized buffer blocks. So if you
> > use fewer bytes than the OS block size you waste the difference between
> > your block size and the block size of the OS cache entry.
> > I'm pretty sure Linux uses a 32K buffer size in its cache, and I'm
> > pretty confident that NT does as well from my previous tests.
> I dunno about NT, but here's a quote from "Linux Kernel Internals"
> 2nd Ed, page 92-93:
> .. The block size for any given device may be 512, 1024, 2048 or
> 4096 bytes....
> ... the buffer cache manages individual block buffers of
> varying size. For this, every block is given a 'buffer_head' data
> structure. ... The definition of the buffer head is in linux/fs.h
> ... the size of this area exactly matches the block size 'b_size'...
> The quote goes on to describe how the data structures are designed to
> be processor-cache-aware.
I double checked the kernel source, and you are right. I stand corrected
about the disk caching.
My assertion stands, it is a neglagable difference to read 32K vs 8K
from a disk, and the probability of data being within a 4 times larger
block is 4 times better, even though the probability of having the
correct block in memory is 4 times less. So, I don't think it is a
numerically significant issue.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2000-11-29 22:09:07|
|Subject: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files |
|Previous:||From: Tom Lane||Date: 2000-11-29 16:53:13|
|Subject: Re: F_SETLK is looking worse and worse... |