All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/7] Store huge page linux pte in mm_struct
Date: Mon, 6 Feb 2012 10:29:57 +0000	[thread overview]
Message-ID: <20120206102957.GB26538@arm.com> (raw)
In-Reply-To: <4F2F352B.9080408@gmail.com>

bill4carson wrote:
> Normal page based pte has hardware version and linux version, these
> two kinds of ptes occupy half of 4K page, and each of two pmd level
> entry pointer to this half 4K page.
>
> For huge page, mappings only exist in pmd level from hardware
> perspective, however mm subsystem also needs to know the linux version
> *pte* of this huge page based mapping, problems is where to store
> these huge page linux pte?
>
> A:
> Store huge page linux pte in mm_struct
>
> B:
> Store huge page linux pte in mm_context_t suggested by Catalin.
> This is almost like option A, while it's nice to modify arm code only
> and take small effort to make it happen.
>
> C:
> Modify pgd_alloc to allocate 2048 pgd_t entries plus two void pointers
> Use these two additional pointers to store huge page linux pte.
> It's feasible, but I don't know whether this is a good idea.

I wouldn't add this to pgd_alloc since not all tasks need huge pages.
First option is also not feasible as we shouldn't touch generic code.
This leaves us with B, unless better options are suggested.

I had a patch couple of years ago
(http://article.gmane.org/gmane.linux.ports.arm.kernel/55045) to use the
AF (Access Flag) bit and free up some bits in the page table, allowing
us to drop the Linux PTE. But we end up in a bigger configuration mess
as we already have to choose between classic MMU and LPAE. The
performance advantage wasn't that big either.

-- 
Catalin

  reply	other threads:[~2012-02-06 10:29 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30  7:57 [RFC] ARM hugetlb support bill4carson at gmail.com
2012-01-30  7:57 ` [PATCH 1/7] Add various hugetlb arm high level hooks bill4carson at gmail.com
2012-02-06 17:07   ` Catalin Marinas
2012-02-07  2:00     ` bill4carson
2012-02-07 11:54       ` Catalin Marinas
2012-02-07 12:15   ` Catalin Marinas
2012-02-07 12:57     ` carson bill
2012-01-30  7:57 ` [PATCH 2/7] Add various hugetlb page table fix bill4carson at gmail.com
2012-01-31  9:57   ` Catalin Marinas
2012-01-31  9:58   ` Russell King - ARM Linux
2012-01-31 12:25     ` Catalin Marinas
2012-02-01  3:10       ` bill4carson
2012-02-06 16:26         ` Catalin Marinas
2012-02-07  1:42           ` bill4carson
2012-02-07 11:50             ` Catalin Marinas
2012-02-07 13:24               ` carson bill
2012-02-07 14:11                 ` Catalin Marinas
2012-02-07 14:46                   ` carson bill
2012-02-07 15:09                     ` Catalin Marinas
2012-02-07 15:41                       ` carson bill
2012-01-30  7:57 ` [PATCH 3/7] Introduce set_hugepte_ext api for huge page hardware page table setup bill4carson at gmail.com
2012-01-30  7:57 ` [PATCH 4/7] Store huge page linux pte in mm_struct bill4carson at gmail.com
2012-01-31  9:37   ` Catalin Marinas
2012-01-31 10:01   ` Russell King - ARM Linux
2012-02-01  5:45     ` bill4carson
2012-02-06  2:04       ` bill4carson
2012-02-06 10:29         ` Catalin Marinas [this message]
2012-02-06 14:40           ` carson bill
2012-01-30  7:57 ` [PATCH 5/7] Using do_page_fault for section fault handling bill4carson at gmail.com
2012-01-30  7:57 ` [PATCH 6/7] Add hugetlb Kconfig option bill4carson at gmail.com
2012-01-30  7:57 ` [PATCH 7/7] Minor compiling fix bill4carson at gmail.com
2012-01-31  9:29 ` [RFC] ARM hugetlb support Catalin Marinas
2012-02-01  1:56   ` bill4carson
2012-02-02 14:38     ` Catalin Marinas
2012-02-03  1:41       ` bill4carson
2012-02-06 16:29         ` Catalin Marinas

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=20120206102957.GB26538@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.