On Wed, 4 Jan 2017, Vlastimil Babka wrote:
> > Hmm, is there a significant benefit to setting "defer" rather than "never"
> > if you can rely on khugepaged to trigger compaction when it tries to
> > allocate. I suppose if there is nothing to collapse that this won't do
> > compaction, but is t
On Wed, 4 Jan 2017, Mel Gorman wrote:
> There is a slight disconnect. The bug reports I'm aware of predate the
> introduction of "defer" and the current "madvise" semantics for defrag. The
> current semantics have not had enough time in the field to generate
> reports. I expect lag before users ar
On Tue, Jan 03, 2017 at 01:57:33PM -0800, David Rientjes wrote:
> On Tue, 3 Jan 2017, Mel Gorman wrote:
>
> > > I sympathize with that, I've dealt with a number of issues that we have
> > > encountered where thp defrag was either at fault or wasn't, and there
> > > were
> > > also suggestions t
On Wed 04-01-17 09:32:55, Vlastimil Babka wrote:
> On 01/03/2017 11:44 PM, David Rientjes wrote:
> > On Mon, 2 Jan 2017, Vlastimil Babka wrote:
[...]
> >>> echo "defer madvise" > /sys/kernel/mm/transparent_hugepage/defrag
> >>> cat /sys/kernel/mm/transparent_hugepage/defrag
> >> always [defer] [mad
On 01/03/2017 11:44 PM, David Rientjes wrote:
> On Mon, 2 Jan 2017, Vlastimil Babka wrote:
>
>> I'm late to the thread (I did read it fully though), so instead of
>> multiple responses, I'll just list my observations here:
>>
>> - "defer", e.g. background kswapd+compaction is not a silver bullet,
On Mon, 2 Jan 2017, Vlastimil Babka wrote:
> I'm late to the thread (I did read it fully though), so instead of
> multiple responses, I'll just list my observations here:
>
> - "defer", e.g. background kswapd+compaction is not a silver bullet, it
> will also affect the system. Mel already mention
On Tue, 3 Jan 2017, Mel Gorman wrote:
> > I sympathize with that, I've dealt with a number of issues that we have
> > encountered where thp defrag was either at fault or wasn't, and there were
> > also suggestions to set defrag to "madvise" to rule it out and that
> > impacted other users.
> >
On Fri, Dec 30, 2016 at 02:30:32PM -0800, David Rientjes wrote:
> On Fri, 30 Dec 2016, Mel Gorman wrote:
>
> > Michal is correct in that my intent for defer was to have "never stall"
> > as the default behaviour. This was because of the number of severe stalls
> > users experienced that lead to r
On 12/22/2016 01:21 AM, David Rientjes wrote:
> Currently, when defrag is set to "madvise", thp allocations will direct
> reclaim. However, when defrag is set to "defer", all thp allocations do
> not attempt reclaim regardless of MADV_HUGEPAGE.
>
> This patch always directly reclaims for MADV_HUG
On Fri, 30 Dec 2016, Mel Gorman wrote:
> Michal is correct in that my intent for defer was to have "never stall"
> as the default behaviour. This was because of the number of severe stalls
> users experienced that lead to recommendations in tuning guides to always
> disable THP. I'd also seen mul
On Fri, Dec 30, 2016 at 01:56:16PM +0100, Michal Hocko wrote:
> On Fri 30-12-16 12:36:20, Mel Gorman wrote:
> [...]
> > I'll neither ack nor nak this patch. However, I would much prefer an
> > additional option be added to sysfs called defer-fault that would avoid
> > all fault-based stalls but sti
On Fri 30-12-16 12:36:20, Mel Gorman wrote:
[...]
> I'll neither ack nor nak this patch. However, I would much prefer an
> additional option be added to sysfs called defer-fault that would avoid
> all fault-based stalls but still potentially stall for MADV_HUGEPAGE.
Would you consider changing the
On Thu, Dec 22, 2016 at 01:05:27PM -0800, David Rientjes wrote:
> On Thu, 22 Dec 2016, Michal Hocko wrote:
>
> > > Currently, when defrag is set to "madvise", thp allocations will direct
> > > reclaim. However, when defrag is set to "defer", all thp allocations do
> > > not attempt reclaim regard
On Wed 28-12-16 13:33:49, David Rientjes wrote:
> On Wed, 28 Dec 2016, Michal Hocko wrote:
>
> > I do care more about _users_ and their _experience_ than what
> > application _writers_ think is the best. This is the whole point
> > of giving the defrag tunable. madvise(MADV_HUGEPAGE) is just a hin
On Wed, 28 Dec 2016, Michal Hocko wrote:
> I do care more about _users_ and their _experience_ than what
> application _writers_ think is the best. This is the whole point
> of giving the defrag tunable. madvise(MADV_HUGEPAGE) is just a hint to
> the system that using transparent hugepages is _pre
On Tue 27-12-16 13:36:54, David Rientjes wrote:
[...]
> All madvised VMAs stall now because THEY WANT TO STALL. It is
> unbelievable that you would claim otherwise or think that you know better
> than the application writer about their application.
I do care more about _users_ and their _experi
On Tue, 27 Dec 2016, Michal Hocko wrote:
> > Important to who?
>
> To all users who want to have THP without stalls experience. This was
> the whole point of 444eb2a449ef ("mm: thp: set THP defrag by default to
> madvise and add a stall-free defrag option").
>
THEY DO NOT STALL. If the applica
On Mon 26-12-16 16:53:39, David Rientjes wrote:
> On Mon, 26 Dec 2016, Michal Hocko wrote:
>
> > But my primary argument is that if you tweak "defer" value behavior
> > then you lose the only "stall free yet allow background compaction"
> > option. That option is really important.
>
> Important t
On Mon, Dec 26, 2016 at 04:53:39PM -0800, David Rientjes wrote:
> > If there is really a need for an immediate solution^Wworkaround then I
> > think that tweaking the madvise option should be reasonably safe. Admins
> > are really prepared for stalls because they are explicitly opting in for
> > ma
On Mon, 26 Dec 2016, Michal Hocko wrote:
> But my primary argument is that if you tweak "defer" value behavior
> then you lose the only "stall free yet allow background compaction"
> option. That option is really important.
Important to who?
What regresses if we kick a background kthread to comp
On Fri 23-12-16 14:46:43, David Rientjes wrote:
[...]
> You want defrag=madvise to start doing background compaction for
> everybody, which was never done before for existing users of
> defrag=madvise? That might be possible, I don't really care, I just think
> it's riskier because there are ex
On Fri, 23 Dec 2016, Michal Hocko wrote:
> > We have no way to compact memory for users who are not using
> > MADV_HUGEPAGE,
>
> yes we have. it is defrag=always. If you do not want direct compaction
> and the resulting allocation stalls then you have to rely on kcompactd
> which is something we
On Fri 23-12-16 02:01:33, David Rientjes wrote:
> On Fri, 23 Dec 2016, Michal Hocko wrote:
>
> > > The offering of defer breaks backwards compatibility with previous
> > > settings of defrag=madvise, where we could set madvise(MADV_HUGEPAGE) on
> > > .text segment remap and try to force thp back
On Fri, 23 Dec 2016, Michal Hocko wrote:
> > The offering of defer breaks backwards compatibility with previous
> > settings of defrag=madvise, where we could set madvise(MADV_HUGEPAGE) on
> > .text segment remap and try to force thp backing if available but not
> > directly reclaim for non VM_
On Thu 22-12-16 13:05:27, David Rientjes wrote:
> On Thu, 22 Dec 2016, Michal Hocko wrote:
>
> > > Currently, when defrag is set to "madvise", thp allocations will direct
> > > reclaim. However, when defrag is set to "defer", all thp allocations do
> > > not attempt reclaim regardless of MADV_HUG
On Thu, 22 Dec 2016, Michal Hocko wrote:
> > Currently, when defrag is set to "madvise", thp allocations will direct
> > reclaim. However, when defrag is set to "defer", all thp allocations do
> > not attempt reclaim regardless of MADV_HUGEPAGE.
> >
> > This patch always directly reclaims for MA
On Wed 21-12-16 16:21:54, David Rientjes wrote:
> Currently, when defrag is set to "madvise", thp allocations will direct
> reclaim. However, when defrag is set to "defer", all thp allocations do
> not attempt reclaim regardless of MADV_HUGEPAGE.
>
> This patch always directly reclaims for MADV_H
On Wed, Dec 21, 2016 at 04:21:54PM -0800, David Rientjes wrote:
> Currently, when defrag is set to "madvise", thp allocations will direct
> reclaim. However, when defrag is set to "defer", all thp allocations do
> not attempt reclaim regardless of MADV_HUGEPAGE.
>
> This patch always directly rec
Currently, when defrag is set to "madvise", thp allocations will direct
reclaim. However, when defrag is set to "defer", all thp allocations do
not attempt reclaim regardless of MADV_HUGEPAGE.
This patch always directly reclaims for MADV_HUGEPAGE regions when defrag
is not set to "never." The id
29 matches
Mail list logo
