From: Darren Hart <dvhart@infradead.org>
To: David Miller <davem@davemloft.net>
Cc: dvhart@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: futex testsuite suggestion...
Date: Sat, 22 Nov 2014 00:02:39 -0800 [thread overview]
Message-ID: <20141122080239.GA7886@vmdeb7> (raw)
In-Reply-To: <20141027.163116.627611711460671434.davem@davemloft.net>
On Mon, Oct 27, 2014 at 04:31:16PM -0400, David Miller wrote:
> From: Darren Hart <dvhart@linux.intel.com>
> Date: Mon, 27 Oct 2014 13:29:14 -0700
>
> > On 10/27/14 12:56, David Miller wrote:
> >> I'd like to suggest that you add a test that triggers transparent
> >> hugepages, because if an architecture doesn't implement
> >> __get_user_pages_fast() such futexes cause a machine to hang.
> >>
> >> I hacked up something simple that took the existing performance
> >> test and made it operate in a register allocated using memalign().
> >>
> >> I would suggest doing a memalign(HUGEPAGE_SIZE, HUGEPAGE_SIZE) then
> >> iterating running a futex test within each normal page within that
> >> hugepage.
> >
> > Do you want this option for the performance tests, or would a less
> > intensive functional test be sufficient?
>
> I think a functional test is sufficient.
Hi David,
>From your suggestion I put together a simple transparent hugepage functional
test. See the "thp" branch, functional/futex_wait_thp.c.
I'd like your thoughts on if this functions as desired. Is the simple single
threaded timeout sufficient, or would you prefer to see a waiter/waker pair of
threads for each iteration?
Some TODOs still:
I wasn't sure if there was a way to test for hugepagesize and my quick search
didn't reveal anything (other than /proc/meminfo).
Check at runtime if the test is getting a huge page, otherwise it just reports
success, but used several regular pages instead.
--
Darren Hart
Intel Open Source Technology Center
next prev parent reply other threads:[~2014-11-23 5:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-27 19:56 futex testsuite suggestion David Miller
2014-10-27 20:29 ` Darren Hart
2014-10-27 20:31 ` David Miller
2014-11-22 8:02 ` Darren Hart [this message]
2014-11-24 22:07 ` David Miller
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=20141122080239.GA7886@vmdeb7 \
--to=dvhart@infradead.org \
--cc=davem@davemloft.net \
--cc=dvhart@linux.intel.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox