Re: [Fwd: Re: 8192 BLCKSZ ?] - Mailing list pgsql-hackers

From mlw
Subject Re: [Fwd: Re: 8192 BLCKSZ ?]
Date
Msg-id 3A257E17.3D18FF6A@mohawksoft.com
Whole thread Raw
In response to [Fwd: Re: 8192 BLCKSZ ?]  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
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.


-- 
http://www.mohawksoft.com


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: F_SETLK is looking worse and worse...
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files