On Thursday, January 16, 2014, Dave Chinner
>
wrote:
> On Thu, Jan 16, 2014 at 03:58:56PM -0800, Jeff Janes wrote:
> > On Thu, Jan 16, 2014 at 3:23 PM, Dave Chinner
> wrote:
> >
> > > On Wed, Jan 15, 2014 at 06:14:18PM -0600, Jim Nasby wrote:
> > > > On 1/15/14, 12:00 AM, Claudio Freire wrote:
>
On Wed, Jan 15, 2014 at 7:53 AM, Mel Gorman wrote:
> The second is have
> pages that are strictly kept dirty until the application syncs them. An
> unbounded number of these pages would blow up but maybe bounds could be
> placed on it. There are no solid conclusions on that part yet.
I think the
On Wed, Jan 15, 2014 at 2:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think that the bottom line is that we're not likely to make massive
>> changes to the way that we do block caching now. Even if some other
>> scheme could work much better on Linux (and so far I'm unconvinced
>> that any
Robert Haas writes:
> I think that the bottom line is that we're not likely to make massive
> changes to the way that we do block caching now. Even if some other
> scheme could work much better on Linux (and so far I'm unconvinced
> that any of the proposals made here would in fact work much bett
On Wed, Jan 15, 2014 at 10:53 AM, Mel Gorman wrote:
> I realise that now and sorry for the noise.
>
> I later read the parts of the thread that covered the strict ordering
> requirements and in a summary mail I split the requirements in two. In one,
> there are dirty sticky pages that the kernel s
On Wed, Jan 15, 2014 at 10:16:27AM -0500, Robert Haas wrote:
> On Wed, Jan 15, 2014 at 4:44 AM, Mel Gorman wrote:
> > That applies if the dirty pages are forced to be kept dirty. You call
> > this pinned but pinned has special meaning so I would suggest calling it
> > something like dirty-sticky p
On Wed, Jan 15, 2014 at 4:44 AM, Mel Gorman wrote:
> That applies if the dirty pages are forced to be kept dirty. You call
> this pinned but pinned has special meaning so I would suggest calling it
> something like dirty-sticky pages. It could be the case that such hinting
> will have the pages ex
On Wed, Jan 15, 2014 at 09:44:21AM +, Mel Gorman wrote:
> >
> > H. What happens if the process crashes after pinning the dirty
> > pages? How do we even know what process pinned the dirty pages so
> > we can clean up after it? What happens if the same page is pinned by
> > multiple proces
(This thread is now massive and I have not read it all yet. If anything
I say has already been discussed then whoops)
On Tue, Jan 14, 2014 at 12:09:46PM +1100, Dave Chinner wrote:
> On Mon, Jan 13, 2014 at 09:29:02PM +, Greg Stark wrote:
> > On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund
> >
On Tue, Jan 14, 2014 at 05:38:10PM -0700, Jonathan Corbet wrote:
> On Wed, 15 Jan 2014 09:23:52 +1100
> Dave Chinner wrote:
>
> > It appears to me that we are seeing large memory machines much more
> > commonly in data centers - a couple of years ago 256GB RAM was only
> > seen in supercomputers.
On Wed, 15 Jan 2014 09:23:52 +1100
Dave Chinner wrote:
> It appears to me that we are seeing large memory machines much more
> commonly in data centers - a couple of years ago 256GB RAM was only
> seen in supercomputers. Hence machines of this size are moving from
> "tweaking settings for superco
On Wed, Jan 15, 2014 at 08:03:28AM +1300, Gavin Flower wrote:
> On 14/01/14 14:09, Dave Chinner wrote:
> >On Mon, Jan 13, 2014 at 09:29:02PM +, Greg Stark wrote:
> >>On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund
> >>wrote:
> [...]
> >>The more ambitious and interesting direction is to let Po
On Tue, Jan 14, 2014 at 2:03 PM, Gavin Flower
wrote:
> Say a byte (this is arbitrary, it could be a single hint bit which meant
> "please, Please, PLEASE don't flush, if that is okay with you Mr
> Kernel..."), so strength would be S = (unsigned byte value)/256, so 0 <= S <
> 1.
>
> S = 0 flus
On 14/01/14 14:09, Dave Chinner wrote:
On Mon, Jan 13, 2014 at 09:29:02PM +, Greg Stark wrote:
On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund wrote:
[...]
The more ambitious and interesting direction is to let Postgres tell
the kernel what it needs to know to manage everything. To do that
On Mon, Jan 13, 2014 at 09:29:02PM +, Greg Stark wrote:
> On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund wrote:
> > For one, postgres doesn't use mmap for files (and can't without major
> > new interfaces). Frequently mmap()/madvise()/munmap()ing 8kb chunks has
> > horrible consequences for pe
On 01/13/2014 11:22 PM, James Bottomley wrote:
>
>> The less exciting, more conservative option would be to add kernel
>> interfaces to teach Postgres about things like raid geometries. Then
>> Postgres could use directio and decide to do prefetching based on the
>> raid geometry, how much availabl
On Mon, 2014-01-13 at 21:29 +, Greg Stark wrote:
> On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund wrote:
> > For one, postgres doesn't use mmap for files (and can't without major
> > new interfaces). Frequently mmap()/madvise()/munmap()ing 8kb chunks has
> > horrible consequences for performan
Everyone,
I am looking for one or more hackers to go to Collab with me to discuss
this. If you think that might be you, please let me know and I'll look
for funding for your travel.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Mon, Jan 13, 2014 at 9:12 PM, Andres Freund wrote:
> For one, postgres doesn't use mmap for files (and can't without major
> new interfaces). Frequently mmap()/madvise()/munmap()ing 8kb chunks has
> horrible consequences for performance/scalability - very quickly you
> contend on locks in the k
19 matches
Mail list logo
