Re: WAL & SHM principles - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: WAL & SHM principles
Date
Msg-id 20010313132153.A29888@fw.wintelcom.net
Whole thread Raw
In response to Re: WAL & SHM principles  (Matthew Kirkwood <matthew@hairy.beasts.org>)
Responses Re: WAL & SHM principles
List pgsql-hackers
* Matthew Kirkwood <matthew@hairy.beasts.org> [010313 13:12] wrote:
> On Tue, 13 Mar 2001, Ken Hirsch wrote:
> 
> > > mlock() guarantees that the locked address space is in memory.  This
> > > doesn't imply that updates are not written to the backing file.
> >
> > I've wondered about this myself.  It _is_ true on Linux that mlock
> > prevents writes to the backing store,
> 
> I don't believe that this is true.  The manpage offers no
> such promises, and the semantics are not useful.

Afaik FreeBSD's Linux emulator:

revision 1.13
date: 2001/02/28 04:30:27;  author: dillon;  state: Exp;  lines: +3 -1
Linux does not filesystem-sync file-backed writable mmap pages on
a regular basis.  Adjust our linux emulation to conform.  This will
cause more dirty pages to be left for the pagedaemon to deal with,
but our new low-memory handling code can deal with it.   The linux
way appears to be a trend, and we may very well make MAP_NOSYNC the
default for FreeBSD as well (once we have reasonable sequential
write-behind heuristics for random faults).
(will be MFC'd prior to 4.3 freeze)

Suggested by: Andrew Gallatin

Basically any mmap'd data doesn't seem to get sync()'d out on
a regular basis.

> > and this is used as a security feature for cryptography software.
> 
> mlock() is used to prevent pages being swapped out.  Its
> use for crypto software is essentially restricted to anon
> memory (allocated via brk() or mmap() of /dev/zero).

What about userland device drivers that want to send parts
of a disk backed file to a driver's dma routine?

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/



pgsql-hackers by date:

Previous
From: Matthew Kirkwood
Date:
Subject: Re: WAL & SHM principles
Next
From: Thomas Swan
Date:
Subject: Re: Performance monitor signal handler