linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Will Deacon <will.deacon@arm.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org, mhocko@suse.cz,
	Steve Capper <steve.capper@arm.com>
Subject: Re: [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c
Date: Wed, 19 Sep 2012 17:53:46 +0200	[thread overview]
Message-ID: <20120919155346.GB32398@linux-mips.org> (raw)
In-Reply-To: <CAHkRjk7uCZZvA_Ubq7vgkAV2r-vMNHxs+hZmvf+99ks+4v7isA@mail.gmail.com>

On Wed, Sep 19, 2012 at 10:12:28AM +0100, Catalin Marinas wrote:

> >> 5) void update_mmu_cache(struct vm_area_struct *vma,
> >>                          unsigned long address, pte_t *ptep)
> >
> > Yes please.
> 
> Should we just use a generic (void *) for the last argument or force a
> cast in mm/huge_memory.c?
> 
> Ralf's point is that transparent huge page code calls update_mmu_cache
> with a (pmd_t *) as the last argument. This could make sense for THP
> as it assumes that huge pages can only be created at the pmd level.
> But that's unlike mm/hugetlb.c which casts huge page types to pte_t,
> even though on ARM they are implemented at the pmd level.
> 
> On ARM (with VIPT caches) update_mmu_cache() is empty like on x86,
> though a static inline rather than macro.

It's even worse - mm/huge_memory.c is passing a pmd_t, not a pointer so
changing the type of update_mmu_cache's 3rd argument alone won't cut it.

This went unnoticed so far because all existing architectures supporting
transparent huge pages implement update_mmu_cache() as do { } while (0).

MIPS uses update_mmu_cache() as the hook to deal with cache aliases and
pre-faulting a TLB entry.  But aliases don't affect small pages and having
a separate variant of update_mmu_cache for huge pages will allow some other
optimizations.  That's minor but it's the argument types that really need
to be fixed and because MIPS also implements huge pages at PMD level I'd
be happy if we settle on pte_t * for mm/huge_memory.c.

  Ralf

  reply	other threads:[~2012-09-19 15:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 16:47 [PATCH 0/3] Minor changes to common hugetlb code for ARM Will Deacon
2012-09-11 16:47 ` [PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() Will Deacon
2012-09-11 17:12   ` Kirill A. Shutemov
2012-09-12 15:30   ` Michal Hocko
2012-09-11 16:47 ` [PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Will Deacon
2012-09-11 17:38   ` Kirill A. Shutemov
2012-09-12 15:40   ` Michal Hocko
2012-09-12 15:51     ` Catalin Marinas
2012-09-15 13:38   ` Ralf Baechle
2012-09-18 19:33     ` Andrew Morton
2012-09-19  9:12       ` Catalin Marinas
2012-09-19 15:53         ` Ralf Baechle [this message]
2012-09-20 12:44           ` Will Deacon
2012-09-20 19:32             ` David Miller
2012-09-11 16:47 ` [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE Will Deacon
2012-09-11 17:41   ` Kirill A. Shutemov
2012-09-12 15:32   ` Michal Hocko
2012-09-12 18:06     ` Chris Metcalf
2012-09-12 18:10       ` Will Deacon
2012-09-13 19:05   ` Andrew Morton
2012-09-13 21:26     ` Will Deacon
2012-09-13 21:27     ` Stephen Rothwell
2012-09-13 21:40       ` Andrew Morton
2012-09-12 15:27 ` [PATCH 0/3] Minor changes to common hugetlb code for ARM Michal Hocko
2012-09-12 15:55   ` Will Deacon
2012-09-13 12:22     ` Michal Hocko
2012-09-13  0:12   ` Andrea Arcangeli

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=20120919155346.GB32398@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=steve.capper@arm.com \
    --cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).