All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Hugh Dickins <hughd@google.com>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Alex Thorlton <athorlton@sgi.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.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>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [PATCH 2/2] mm: thp: kill the bogus ->def_flags check in hugepage_madvise()
Date: Thu, 23 Jan 2014 17:43:34 +0100	[thread overview]
Message-ID: <20140123164334.GA7097@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.11.1401221209520.1541@eggly.anvils>

On 01/22, Hugh Dickins wrote:
>
> On Wed, 22 Jan 2014, Oleg Nesterov wrote:
>
> > hugepage_madvise() checks "mm->def_flags & VM_NOHUGEPAGE" but
> > this can be never true, currently mm->def_flags can only have
> > VM_LOCKED.
>
> But line 1087 of arch/s390/mm/pgtable.c says
> 	mm->def_flags |= VM_NOHUGEPAGE;
> from 3eabaee998c787e7e1565574821652548f7fc003
> "KVM: s390: allow sie enablement for multi-threaded programs".

Argh. Thanks Hugh!

Another case when I forgot about /bin/grep. So the patch is wrong,
at least the changelog is certainly is. I am stupid.

But, perhaps, this all still can work? Looks like, s390 already
implements PR_SET_THP_DISABLE using the same idea, it would be
nice to avoid another hack.

Gerald, any chance we can revert 8e72033f2a489 "thp: make MADV_HUGEPAGE
check for mm->def_flags" ? The changelog says "In order to also prevent
MADV_HUGEPAGE on such an mm", is it really important? I mean, if the
application calls madvise(MADV_HUGEPAGE) it should probably know what
it does and, this can be useful after if PR_SET_THP_DISABLE or
KVM_S390_ENABLE_SIE. Of course I do not understand this code, perhaps
MADV_HUGEPAGE is simply impossible.

Another question, can't fork/exec preserve VM_NOHUGEPAGE in ->def_flags?
This is what PR_SET_THP_DISABLE wants.

I'll send you mbox with the previous discussion privately.

Thanks,

Oleg.


  reply	other threads:[~2014-01-23 16:44 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
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 [this message]
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=20140123164334.GA7097@redhat.com \
    --to=oleg@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=athorlton@sgi.com \
    --cc=benh@kernel.crashing.org \
    --cc=ebiederm@xmission.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hughd@google.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=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=schwidefsky@de.ibm.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.