it's a case of picking some of
these hinting wishlists, seeing what it takes to implement it in kernel
and testing it with a suitably patched version of postgres running a test
case driven by something (pgbench presumably).
--
Mel Gorman
SUSE Labs
--
Sent via pgsql-hackers mailing list (pgsql
dedicated group. That hopefully will result in a small number of
concrete proposals that can be turned into patches over time.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to the conclusion that temp files can be larger
than memory so tmpfs isn't the solution here. :)
And swap IO patterns blow chunks because people rarely want to touch
that area of the code with a 50 foot pole. It gets filed under if you're
swapping, you already lost
--
Mel Gorman
SUSE Labs
--
Sent via
On Fri, Jan 17, 2014 at 03:24:01PM -0500, Gregory Smith wrote:
On 1/17/14 10:37 AM, Mel Gorman wrote:
There is not an easy way to tell. To be 100%, it would require an
instrumentation patch or a systemtap script to detect when a
particular page is being written back and track the context
On Thu, Jan 16, 2014 at 04:30:59PM -0800, Jeff Janes wrote:
On Wed, Jan 15, 2014 at 2:08 AM, Mel Gorman mgor...@suse.de wrote:
On Tue, Jan 14, 2014 at 09:30:19AM -0800, Jeff Janes wrote:
That could be something we look at. There are cases buried deep in the
VM where pages get
On Wed, Jan 15, 2014 at 02:14:08PM +, Mel Gorman wrote:
One assumption would be that Postgres is perfectly happy with the current
kernel behaviour in which case our discussion here is done.
It has been demonstrated that this statement was farcical. The thread is
massive just from
On Fri, Jan 17, 2014 at 06:14:37PM +0100, Andres Freund wrote:
Hi Mel,
On 2014-01-17 16:31:48 +, Mel Gorman wrote:
Direct IO, buffered IO, double buffering and wishlists
--
3. Hint that a page should be dropped immediately when
.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
.
FWIW, the performance of some IO benchmarks used to depend on whether they
could create, write and delete files before any of the data actually hit
the disk -- pretty much exactly the type of behaviour you are looking for.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql-hackers mailing list (pgsql
On Wed, Jan 15, 2014 at 09:44:21AM +, Mel Gorman wrote:
SNIP
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 processes
but it's far from being a free lunch and it has costs
that read/write does not have to deal with. Maybe some of these problems
can be fixed or mitigated but it is a case where a test case demonstrates
the problem even if that requires patching PostgreSQL.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql
are more viable than
others. Ultimately we would still need a test case showing the benefit
even if that depends on a Postgres patch taking advantage of a new
feature.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Wed, Jan 15, 2014 at 10:16:27AM -0500, Robert Haas wrote:
On Wed, Jan 15, 2014 at 4:44 AM, Mel Gorman mgor...@suse.de 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
On Mon, Jan 13, 2014 at 03:24:38PM -0800, Josh Berkus wrote:
On 01/13/2014 02:26 PM, Mel Gorman wrote:
Really?
zone_reclaim_mode is often a complete disaster unless the workload is
partitioned to fit within NUMA nodes. On older kernels enabling it would
sometimes cause massive stalls
as a hint, we'd need something a lot more
concrete than you should test more.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
kernel version and see can it be verified with a test case or did we
manage to break something else in the process. Other bugs may still
exist because we believe some interface works how users want when it is
in fact unfit for purpose for some reason.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql
be reliably implemented.
--
Mel Gorman
SUSE Labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 13, 2014 at 11:38:44PM +0100, Jan Kara wrote:
On Mon 13-01-14 22:26:45, Mel Gorman wrote:
The flipside is also meant to hold true. If you know data will be needed
in the near future then posix_fadvise(POSIX_FADV_WILLNEED). Glancing at
the implementation it does a forced read
18 matches
Mail list logo
