All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] hugepages on sparc
@ 2016-01-27 22:29 Nitin Gupta
  2016-01-27 23:17 ` David Miller
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Nitin Gupta @ 2016-01-27 22:29 UTC (permalink / raw)
  To: sparclinux

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-01-29  5:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-27 22:29 [RFC] hugepages on sparc Nitin Gupta
2016-01-27 23:17 ` 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

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.