From: Alex Thorlton <athorlton@sgi.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Rik van Riel <riel@redhat.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andy Lutomirski <luto@amacapital.net>,
Al Viro <viro@zeniv.linux.org.uk>,
Kees Cook <keescook@chromium.org>,
Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC PATCHv2 2/2] Change khugepaged to respect MMF_THP_DISABLE flag
Date: Mon, 20 Jan 2014 14:41:08 -0600 [thread overview]
Message-ID: <20140120204108.GE18196@sgi.com> (raw)
In-Reply-To: <20140120201525.GA31416@redhat.com>
On Mon, Jan 20, 2014 at 09:15:25PM +0100, Oleg Nesterov wrote:
> On 01/20, Alex Thorlton wrote:
> >
> > No, definitely not. Upon review, khugepaged_test_exit is the wrong
> > place to do this check. I think I need to move it up to
> > khugepaged_scan_mm_slot for this to work correctly.
>
> Why? unless a MMF_THP_DISABLE task does madvise(MADV_HUGEPAGE)
> khugepaged_scan_mm_slot() should never see its ->mm ?
>
> Although I got lost a bit, and probably misunderstood... but it
> seems to me that whatever you do this patch should not touch
> khugepaged_scan_mm_slot.
Maybe I've gotten myself confused as well :) After looking through the
code some more, my understanding is that khugepaged_test_exit is used to
make sure that __khugepaged_exit isn't running from underneath at certain
times, so to have khugepaged_test_exit return true when __khugepaged_exit
is not necessarily running, seems incorrect to me.
I think the check for MMF_THP_DISABLE should occur at the same time as
we check khugepaged_test_exit, but should occur separately, since I
don't really believe the two checks are related. Something like this in
khugepaged_scan_mm_slot:
mm = mm_slot->mm;
down_read(&mm->mmap_sem);
- if (unlikely(khugepaged_test_exit(mm)))
+ if (unlikely(khugepaged_test_exit(mm) || check_mmf_thp_disable(mm)))
vma = NULL;
else
vma = find_vma(mm, khugepaged_scan.address);
progress++;
I think this makes more sense, but I may not be looking at this
correctly. Thoughts?
- Alex
next prev parent reply other threads:[~2014-01-20 20:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 21:01 [RFC PATCHv2 1/2] Add mm flag to control THP Alex Thorlton
2014-01-16 21:01 ` [RFC PATCHv2 2/2] Change khugepaged to respect MMF_THP_DISABLE flag Alex Thorlton
2014-01-17 20:34 ` Oleg Nesterov
2014-01-17 22:58 ` Alex Thorlton
2014-01-18 23:49 ` Kirill A. Shutemov
2014-01-20 19:58 ` Alex Thorlton
2014-01-20 20:15 ` Oleg Nesterov
2014-01-20 20:41 ` Alex Thorlton [this message]
2014-01-22 17:45 ` [PATCH 0/2] mm->def_flags cleanups (Was: Change khugepaged to respect MMF_THP_DISABLE flag) Oleg Nesterov
2014-01-22 17:46 ` [PATCH 1/2] exec: kill the unnecessary mm->def_flags setting in load_elf_binary() Oleg Nesterov
2014-01-22 17:46 ` [PATCH 2/2] mm: thp: kill the bogus ->def_flags check in hugepage_madvise() Oleg Nesterov
2014-01-22 20:16 ` Hugh Dickins
2014-01-23 16:43 ` Oleg Nesterov
2014-01-24 14:19 ` Gerald Schaefer
2014-01-22 18:11 ` [PATCH 0/2] mm->def_flags cleanups (Was: Change khugepaged to respect MMF_THP_DISABLE flag) Oleg Nesterov
2014-01-22 18:40 ` Alex Thorlton
2014-01-22 19:25 ` Oleg Nesterov
2014-01-22 19:43 ` Oleg Nesterov
2014-01-22 20:02 ` Alex Thorlton
2014-01-23 16:47 ` Oleg Nesterov
2014-01-17 19:54 ` [RFC PATCHv2 1/2] Add mm flag to control THP Andy Lutomirski
2014-01-17 22:54 ` Alex Thorlton
2014-01-17 20:09 ` Oleg Nesterov
2014-01-17 22:52 ` Alex Thorlton
2014-01-18 23:41 ` Kirill A. Shutemov
2014-01-20 17:26 ` Alex Thorlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140120204108.GE18196@sgi.com \
--to=athorlton@sgi.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.