Skip site navigation (1) Skip section navigation (2)

Re: [Fwd: Re: 8192 BLCKSZ ?]

From: mlw <markw(at)mohawksoft(dot)com>
To: kogorman(at)pacbell(dot)net, Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Fwd: Re: 8192 BLCKSZ ?]
Date: 2000-11-29 22:07:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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.


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2000-11-29 22:09:07
Subject: Re: [GENERAL] Warning: Don't delete those /tmp/.PGSQL.* files
Previous:From: Tom LaneDate: 2000-11-29 16:53:13
Subject: Re: F_SETLK is looking worse and worse...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group