From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Sean Chittenden <sean(at)chittenden(dot)org>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: O_DIRECT in freebsd |
Date: | 2003-06-23 02:45:06 |
Message-ID: | 200306230245.h5N2j6215483@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > _That_ is an excellent point. However, do we know at the time we open
> > the file descriptor if we will be doing this?
>
> We'd have to say on a per-read basis whether we want O_DIRECT or not,
> and fd.c would need to provide a suitable file descriptor.
OK
> > What about cache
> > coherency problems with other backends not opening with O_DIRECT?
>
> If O_DIRECT introduces cache coherency problems against other processes
> not using O_DIRECT then the whole idea is a nonstarter, but I can't
> imagine any kernel hackers would have been stupid enough to allow that
> to happen ...
Seeing how the buffer exists in user space, I would be interested how
they prevent coherency problems with good performance --- maybe they map
the same page into multiple processes --- that would be interesting,
though it would require some locking.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Sean Chittenden | 2003-06-23 02:46:56 | Re: O_DIRECT in freebsd |
Previous Message | Bruce Momjian | 2003-06-23 02:43:36 | Re: O_DIRECT in freebsd |