linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Hugh Dickins <hughd@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] thp+memcg-numa: fix BUG at include/linux/mm.h:370!
Date: Mon, 14 Mar 2011 09:56:10 -0700	[thread overview]
Message-ID: <AANLkTikvt+o+UaksmvM5C7FWt7hTMJyaPiUGhQ+6OKBg@mail.gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1103140910570.2601@sister.anvils>

On Mon, Mar 14, 2011 at 9:37 AM, Hugh Dickins <hughd@google.com> wrote:
>
> I did try it that way at first (didn't help when I mistakenly put
> #ifndef instead of #ifdef around the put_page!), but was repulsed
> by seeing yet another #ifdef CONFIG_NUMA, so went with the duplicating
> version - which Linus has now taken.

I have to admit to being repulsed by the whole patch, but my main
source of "that's effin ugly" was from the crazy lock handling.

Does mem_cgroup_newpage_charge() even _need_ the mmap_sem at all? And
if not, why not release the read-lock early? And even if it _does_
need it, why not do

    ret = mem_cgroup_newpage_charge();
    up_read(&mm->mmap_sem);
    if (ret) {
        ...

finally, the #ifdef CONFIG_NUMA is ugly, but it's ugly in the return
path of the function too, and the nicer way would probably be to have
it in one place and do something like

    /*
     * The allocation rules are different for the NUMA/non-NUMA cases
     * For the NUMA case, we allocate here, for the non-numa case we
     * use the allocation in *hpage
     */
    static inline struct page *collapse_alloc_hugepage(struct page **hpage)
    {
    #ifdef CONFIG_NUMA
        VM_BUG_ON(*hpage);
        return alloc_hugepage_vma(khugepaged_defrag(), vma, address, node);
    #else
        VM_BUG_ON(!*hpage);
        return *hpage;
    #endif
    }

    static inline void collapse_free_hugepage(struct page *page)
    {
    #ifdef CONFIG_NUMA
        put_page(new_page);
    #else
        /* Nothing to do */
    #endif
    }

and use that instead. The point being that the #ifdef'fery now ends up
being in a much more targeted area and much better abstracted, rather
than in the middle of code, and ugly as sin.

But as mentioned, the lock handling is disgusting. Why is it even safe
to drop and re-take the lock at all?

                                   Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-03-14 17:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-14  8:08 Hugh Dickins
2011-03-14 15:25 ` Minchan Kim
2011-03-14 15:52 ` Andrea Arcangeli
2011-03-14 16:37   ` Hugh Dickins
2011-03-14 16:56     ` Linus Torvalds [this message]
2011-03-14 17:17       ` Andrea Arcangeli
2011-03-14 19:58         ` Johannes Weiner
2011-03-14 23:42           ` KAMEZAWA Hiroyuki
2011-04-01 21:21           ` Andrea Arcangeli
2011-03-14 16:59     ` [PATCH] mm: PageBuddy and mapcount underflows robustness Andrea Arcangeli
2011-03-14 17:30       ` Linus Torvalds
2011-03-17 23:16         ` Andrea Arcangeli
2011-03-18 21:34           ` Hugh Dickins
2011-03-23 22:58             ` [stable] " Greg KH

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=AANLkTikvt+o+UaksmvM5C7FWt7hTMJyaPiUGhQ+6OKBg@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox