From: Nitin Gupta <nitin.m.gupta@oracle.com>
To: sparclinux@vger.kernel.org
Subject: [RFC] hugepages on sparc
Date: Wed, 27 Jan 2016 22:29:49 +0000 [thread overview]
Message-ID: <56A944DD.3060809@oracle.com> (raw)
Hi,
I wanted to use 4M hugepages but found that kernel only supports
non-HW backed 8M hugepages on SPARC. I see the change was made by this
commit: http://permalink.gmane.org/gmane.linux.ports.sparc/18407
I'm not a hugepage expert but as I understand, this change in default
hugepage size is due to the way transparent hugepage (THP) is
implemented, which looks at memory in PMD size increments and PMD
happens to be 8M aligned. Correct? If this THP design is the only
reason why we have moved from 4M to 8M as default hugepage size then I
think it would be better to fix THP instead.
THP code in mm/huge_memory.c also seems to assume an x86 style page
table (depends on "PMD" size etc.). This seems not ideal for
architectures like SPARC where any data structure like hash table can
be used for page tables. So, shouldn't THP code be using some API to
figure out hugepage backing status of a memory area?
Do you think it would be worth fixing THP as above (remove constrain
for hugepage to be PMD aligned) to at least allow enabling hw-backed
hugepage size as default again?
The whole notion of "default hugepage size" looks weird to me. Ideally
there should be equivalent support for all (most?) hw-backed
hugepapges and THP should be able to work with all kernel supported
pages.
Thanks,
Nitin
next reply other threads:[~2016-01-27 22:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 22:29 Nitin Gupta [this message]
2016-01-27 23:17 ` [RFC] hugepages on sparc David Miller
2016-01-28 19:22 ` Nitin Gupta
2016-01-28 21:47 ` Sam Ravnborg
2016-01-28 22:44 ` David Miller
2016-01-29 5:28 ` Nitin Gupta
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=56A944DD.3060809@oracle.com \
--to=nitin.m.gupta@oracle.com \
--cc=sparclinux@vger.kernel.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.