Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On 2016-02-17 16:17:44 -0500, Rik van Riel wrote: > On Fri, 12 Feb 2016 20:35:53 +0100 > Andres Freund wrote: > > > On 2016-02-12 13:46:53 +0100, Andres Freund wrote: > > > I'm wondering why pages that are repeatedly written to, in units above > > > the page size, are

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On 2016-02-17 16:17:44 -0500, Rik van Riel wrote: > On Fri, 12 Feb 2016 20:35:53 +0100 > Andres Freund wrote: > > > On 2016-02-12 13:46:53 +0100, Andres Freund wrote: > > > I'm wondering why pages that are repeatedly written to, in units above > > > the page size, are promoted to the active

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi Johannes, On 2016-02-12 15:24:05 -0500, Johannes Weiner wrote: > I've updated the patch to work with cgroups. Are tests of this patch, in contrast to the earlier version, necessary? If so, what's this patch based upon? Because it doesn't seem to apply cleanly to any tree I know about. Not

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi Johannes, On 2016-02-12 15:24:05 -0500, Johannes Weiner wrote: > I've updated the patch to work with cgroups. Are tests of this patch, in contrast to the earlier version, necessary? If so, what's this patch based upon? Because it doesn't seem to apply cleanly to any tree I know about. Not

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Fri, 12 Feb 2016 20:35:53 +0100 Andres Freund wrote: > On 2016-02-12 13:46:53 +0100, Andres Freund wrote: > > I'm wondering why pages that are repeatedly written to, in units above > > the page size, are promoted to the active list? I mean if there never > > are any reads

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Fri, 12 Feb 2016 20:35:53 +0100 Andres Freund wrote: > On 2016-02-12 13:46:53 +0100, Andres Freund wrote: > > I'm wondering why pages that are repeatedly written to, in units above > > the page size, are promoted to the active list? I mean if there never > > are any reads or re-dirtying an

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Fri, Feb 12, 2016 at 08:35:53PM +0100, Andres Freund wrote: > To make an actually usable patch out of this it seems we'd have to add a > 'partial' argument to grab_cache_page_write_begin(), so writes to parts > of a page still cause the pages to be marked active. Is it preferrable > to change

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Fri, Feb 12, 2016 at 08:35:53PM +0100, Andres Freund wrote: > To make an actually usable patch out of this it seems we'd have to add a > 'partial' argument to grab_cache_page_write_begin(), so writes to parts > of a page still cause the pages to be marked active. Is it preferrable > to change

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Thu, Feb 11, 2016 at 03:34:04PM -0500, Rik van Riel wrote: > On Tue, 9 Feb 2016 17:42:56 -0500 > Johannes Weiner wrote: > > On Tue, Feb 09, 2016 at 05:52:40PM +0100, Andres Freund wrote: > > > > Rik asked me about active/inactive sizing in /proc/meminfo: > > > Active: 7860556 kB > >

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On 2016-02-12 13:46:53 +0100, Andres Freund wrote: > I'm wondering why pages that are repeatedly written to, in units above > the page size, are promoted to the active list? I mean if there never > are any reads or re-dirtying an already-dirty page, what's the benefit > of moving that page onto

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi, On 2016-02-11 15:34:04 -0500, Rik van Riel wrote: > diff --git a/mm/vmscan.c b/mm/vmscan.c > index eb3dd37ccd7c..0a316c41bf80 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1928,13 +1928,14 @@ static inline bool inactive_anon_is_low(struct lruvec > *lruvec) > */ > static bool

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi, On 2016-02-11 15:34:04 -0500, Rik van Riel wrote: > Andres, does this patch work for you? TL;DR: The patch helps, there might be some additional, largely independent, further improvements. So, I tested this. And under the right set of cirumstances the results are pretty good: - -

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi, On 2016-02-11 15:34:04 -0500, Rik van Riel wrote: > Andres, does this patch work for you? TL;DR: The patch helps, there might be some additional, largely independent, further improvements. So, I tested this. And under the right set of cirumstances the results are pretty good: - -

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi, On 2016-02-11 15:34:04 -0500, Rik van Riel wrote: > diff --git a/mm/vmscan.c b/mm/vmscan.c > index eb3dd37ccd7c..0a316c41bf80 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1928,13 +1928,14 @@ static inline bool inactive_anon_is_low(struct lruvec > *lruvec) > */ > static bool

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On 2016-02-12 13:46:53 +0100, Andres Freund wrote: > I'm wondering why pages that are repeatedly written to, in units above > the page size, are promoted to the active list? I mean if there never > are any reads or re-dirtying an already-dirty page, what's the benefit > of moving that page onto

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Thu, Feb 11, 2016 at 03:34:04PM -0500, Rik van Riel wrote: > On Tue, 9 Feb 2016 17:42:56 -0500 > Johannes Weiner wrote: > > On Tue, Feb 09, 2016 at 05:52:40PM +0100, Andres Freund wrote: > > > > Rik asked me about active/inactive sizing in /proc/meminfo: > > > Active:

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Tue, 9 Feb 2016 17:42:56 -0500 Johannes Weiner wrote: > On Tue, Feb 09, 2016 at 05:52:40PM +0100, Andres Freund wrote: > > Rik asked me about active/inactive sizing in /proc/meminfo: > > Active: 7860556 kB > > Inactive:5395644 kB > > Active(anon):2874936 kB > >

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

On Tue, 9 Feb 2016 17:42:56 -0500 Johannes Weiner wrote: > On Tue, Feb 09, 2016 at 05:52:40PM +0100, Andres Freund wrote: > > Rik asked me about active/inactive sizing in /proc/meminfo: > > Active: 7860556 kB > > Inactive:5395644 kB > > Active(anon):

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi, On Tue, Feb 09, 2016 at 05:52:40PM +0100, Andres Freund wrote: > Hi, > > I'm working on fixing long IO stalls with postgres. After some > architectural changes fixing the worst issues, I noticed that indivdiual > processes/backends/connections still spend more time waiting than I'd > expect.

Re: Unhelpful caching decisions, possibly related to active/inactive sizing

Hi, On Tue, Feb 09, 2016 at 05:52:40PM +0100, Andres Freund wrote: > Hi, > > I'm working on fixing long IO stalls with postgres. After some > architectural changes fixing the worst issues, I noticed that indivdiual > processes/backends/connections still spend more time waiting than I'd > expect.