lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 22 Nov 2014 00:02:39 -0800
From:	Darren Hart <dvhart@...radead.org>
To:	David Miller <davem@...emloft.net>
Cc:	dvhart@...ux.intel.com, linux-kernel@...r.kernel.org
Subject: Re: futex testsuite suggestion...

On Mon, Oct 27, 2014 at 04:31:16PM -0400, David Miller wrote:
> From: Darren Hart <dvhart@...ux.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ