[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150313201954.GB28848@dhcp22.suse.cz>
Date: Fri, 13 Mar 2015 21:19:54 +0100
From: Michal Hocko <mhocko@...e.cz>
To: Eric B Munson <emunson@...mai.com>
Cc: Rik van Riel <riel@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Thomas Gleixner <tglx@...utronix.de>,
Christoph Lameter <cl@...ux.com>,
Peter Zijlstra <peterz@...radead.org>,
Mel Gorman <mgorman@...e.de>,
David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V5] Allow compaction of unevictable pages
On Fri 13-03-15 15:09:15, Eric B Munson wrote:
> On Fri, 13 Mar 2015, Rik van Riel wrote:
>
> > On 03/13/2015 01:26 PM, Eric B Munson wrote:
> >
> > > --- a/mm/compaction.c
> > > +++ b/mm/compaction.c
> > > @@ -1046,6 +1046,8 @@ typedef enum {
> > > ISOLATE_SUCCESS, /* Pages isolated, migrate */
> > > } isolate_migrate_t;
> > >
> > > +int sysctl_compact_unevictable;
> > > +
> > > /*
> > > * Isolate all pages that can be migrated from the first suitable block,
> > > * starting at the block pointed to by the migrate scanner pfn within
> >
> > I suspect that the use cases where users absolutely do not want
> > unevictable pages migrated are special cases, and it may make
> > sense to enable sysctl_compact_unevictable by default.
>
> Given that sysctl_compact_unevictable=0 is the way the kernel behaves
> now and the push back against always enabling compaction on unevictable
> pages, I left the default to be the behavior as it is today.
The question is _why_ we have this behavior now. Is it intentional?
e46a28790e59 (CMA: migrate mlocked pages) is a precedence in that
direction. Vlastimil has then changed that by edc2ca612496 (mm,
compaction: move pageblock checks up from isolate_migratepages_range()).
There is no mention about mlock pages so I guess it was more an
unintentional side effect of the patch. At least that is my current
understanding. I might be wrong here.
The thing about RT is that it is not usable with the upstream kernel
without the RT patchset AFAIU. So the default should be reflect what is
better for the standard kernel. RT loads have to tune the system anyway
so it is not so surprising they would disable this option as well. We
should help those guys and do not require them to touch the code but the
knob is reasonable IMHO.
Especially when your changelog suggests that having this enabled by
default is beneficial for the standard kernel.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists