From: Sam Ravnborg <sam@ravnborg.org>
To: sparclinux@vger.kernel.org
Subject: Re: [RFC] hugepages on sparc
Date: Thu, 28 Jan 2016 21:47:24 +0000 [thread overview]
Message-ID: <20160128214724.GA32638@ravnborg.org> (raw)
In-Reply-To: <56A944DD.3060809@oracle.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1847 bytes --]
On Thu, Jan 28, 2016 at 11:22:52AM -0800, Nitin Gupta wrote:
>
>
> On 01/27/2016 03:17 PM, David Miller wrote:
> > From: Nitin Gupta <nitin.m.gupta@oracle.com>
> > Date: Wed, 27 Jan 2016 14:29:49 -0800
> >
>
> >
> > I don't see what the problem with 8MB huge pages are, they work really
> > well and the implementation is incredibly straightforward.
> >
> > You have to demonstrate a performance of behavioral problem to justify
> > such work. Then you have to come up with an implementation of the
> > THP ABI changes, and satisfy the THP and mm maintainers.
> >
>
> 8M pages don't seem to work too well:
>
> I ran stream benchmark:
> https://www.cs.virginia.edu/stream/ref.html
>
> On a SPARC T4 (128 CPUs, 128G RAM) running 4.5.0-rc1, I got CPU
> lockups and the test seems to get stuck near initialization. The
> same test completed on the same hardware in 1m53s with normal 8K
> pages. The test allocates a total of 48G of RAM and I forced it
> to use hugepages with 'hugectl --heap=8M'. I passed hugepages92
> as kernel boot param to make sure all 48G could be allocated with
> hugepages.
>
> Since 8M seems not quite functional, I can work on getting back 4M
> pages with hopefully decent performance. This would temporarily
> break THP on sparc/linux but it would allow me to split the work
> in phases.
Before introducing anything new it would be good to have the current
functionality fixed. Then you have something working that can be improved.
And you seem to know the area, have access to HW and can reproduce the bug.
So is this something you could at least try to spend some time on before
starting a bigger rewrite?
Sam
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-01-28 21:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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=20160128214724.GA32638@ravnborg.org \
--to=sam@ravnborg.org \
--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.