From: Subrata Modak <subrata@linux.vnet.ibm.com>
To: Darren Hart <dvhltc@us.ibm.com>, Mike Frysinger <vapier@gentoo.org>
Cc: LTP <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] futex syscall tests
Date: Mon, 03 Aug 2009 16:50:59 +0530 [thread overview]
Message-ID: <1249298459.7460.34.camel@subratamodak.linux.ibm.com> (raw)
In-Reply-To: <4A736253.90209@us.ibm.com>
Hi Darren,
On Fri, 2009-07-31 at 14:29 -0700, Darren Hart wrote:
> Mike Frysinger wrote:
> > are there any futex syscall tests already in ltp that i cant seem to locate ?
> > if not, i can adapt the few that already exist in the libfutex code ...
> > -mike
>
> Mike,
>
> I recently done a lot of cleanup and a couple feature additions to the
> kernel futex code. In doing so I was noticing the lack of a good futex
> system call test suite. I had started a writeup of what such a test
> suite should accomplish. I hadn't decided if I wanted to push it to LTP
I would request you to eventually push it to LTP. I think Mike might be
interested in reviewing the initial test code and then suggest his
additions/deletions. That way it would work fine, until Mike has already
written something for this.
And thanks for sharing the below design information.
Regards--
Subrata
> eventually or not. As it sounds like you may have similar interests in
> this test, please find my very early, very incomplete, initial thoughts
> on such a testsuite.
>
> I'd welcome your thoughts on approach, direction, etc.
>
> -------------------------------------------------------------------------------
>
> The following is a start at what I hope to be a design document for a new
> exhaustive futex functional/performance/stress benchmark. Before I flesh it
> out any further, I'd really appreciate some feedback on what I have so far.
>
> Given the number of permutations each test seems to require, I think some kind
> of "test generator" is needed. We will have to describe the permutations and
> pass them to the test generator so it can create the various versions of the
> tests.
>
> HAVOC FUTEX
> ===========
>
> Havoc Futex is intended to thoroughly test the Linux kernel futex system call
> API. To the extent possible, each test is implemented using raw system calls
> as well as the glibc pthread library.
>
> Futex Op Codes
> --------------
> FUTEX_WAIT
> FUTEX_WAKE
> FUTEX_FD
> FUTEX_REQUEUE
> FUTEX_CMP_REQUEUE
> FUTEX_WAKE_OP
> FUTEX_LOCK_PI
> FUTEX_UNLOCK_PI
> FUTEX_TRYLOCK_PI
> FUTEX_WAIT_BITSET
> FUTEX_WAKE_BITSET
> FUTEX_WAIT_REQUEUE_PI
> FUTEX_CMP_REQUEUE_PI
>
> Syscalls to Test
> ----------------
> futex_wake
> futex_wake_op
> futex_requeue
> futex_wait
> futex_lock_pi
> futex_unlock_pi
> futex_wait_requeue_pi
>
> Functional Tests
> ----------------
> requeue_pi/*
> Exercise the FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI op codes,
> under every possible combination of the following scenarios:
>
> o shared and private futexes
> o CLOCK_MONOTONIC and CLOCK_REALTIME timeouts (and none)
> o Signal handling prior to and post requeue
> o correct and incorrect settings for val
> o target futex owned by waker, owned by third party, unowned
> o OWNERDIED reclaim of mutex
> o ensure priority ordered wakeup of waiters
>
> Error and Misuse Cases
> ----------------------
> o mixed shared and private futexes (should fail)
> o pi source futex
> o non-pi target futex
> o unmapped shared futex fault handling
> o bogus uaddrs
> o invalid nr_wake and nr_requeue values
> o mismatched wait_requeue and futex_requeue target futexes
> o incorrect pairing of futex_wait_requeue_pi with futex_wake
>
> Syscalls Exercised
> ------------------
> futex_wait_requeue_pi
> futex_requeue
> futex_lock_pi
> futex_unlock_pi
>
> pi_lock/*
> Exercise the FUTEX_LOCK_PI and FUTEX_UNLOCK_PI op codes, under every
> possible combination of the following scenarious:
>
> o shared and private futexes
> o CLOCK_MONOTONIC and CLOCK_REALTIME timeouts (and none)
> o Signal handling
> o correct and incorrect settings for val
> o bogus uaddrs
> o contended and uncontended cases
> o OWNERDIED reclaim of mutex
>
> Error and Misuse Cases
> ----------------------
> o pi_unlock of a non-pi-locked futex
> o pi_lock of an owned non-pi futex
> o unmapped shared futex fault handling
> o mismatched futex_lock_pi and futex_wake(_op)? calls
> o mismatched futex_wait and futex_unlock_pi calls
>
> Syscalls Exercised
> ------------------
> futex_lock_pi
> futex_unlock_pi
> futex_wait
> futex_wake
> futex_wake_op
>
> requeue/*
> Exercise the FUTEX_WAIT and the FUTEX_CMP_REQUEUE op codes. Perform
> basic testing for FUTEX_REQUEUE, purposefully avoiding its known
> flaws.
>
> Error and Misuse Cases
> ----------------------
>
> Syscalls Exercised
> ------------------
> futex_wait
> futex_requeue
>
> wait/*
> Exercise the FUTEX_WAIT and FUTEX_WAKE op codes.
>
> Error and Misuse Cases
> ----------------------
>
> Syscalls Exercised
> ------------------
> futex_wait
> futex_wake
> futex_wake_op
>
>
>
> Performance Tests
> -----------------
> o attempt to expose lock contention issues, such as those exposed by
> calling futex_wait on an unowned futex
> o rapid lock and unlock of an uncontended futex
> o rapid lock and unlock of a heavily conteded futex
> o attempt to expose bottlenecks imposed by the shared hash-bucket
> implementation
> o attempt to expose real-time scheduling overhead
>
> Stress Tests
> ------------
> o thousands of threads/processes contending on a single futex
> o thousands of threads/processes on thousands of futexes
>
> Other Thoughts
> --------------
> kernel-side futex fault injection
> There are a lot of places in futex.c that have to handle faults. I
> think some kind of a fault injection system is needed. This could be
> enabled via a sysctl or perhaps just configured in to a debug kernel.
> Running this test suite in a loop would allow us to achieve some
> statistical confidence in these numerous fault paths.
>
> FUTEX_REQUEUE
> This op code is deprecated in favor of FUTEX_CMP_REQUEUE. Do to the
> unreliable nature of the op code, only very limited testing can be
> performed.
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2009-08-03 11:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-03 20:01 [LTP] futex syscall tests Mike Frysinger
2009-07-06 15:51 ` Subrata Modak
2009-07-30 12:44 ` Subrata Modak
2009-07-31 21:29 ` Darren Hart
2009-08-03 11:20 ` Subrata Modak [this message]
2009-08-13 9:09 ` Mike Frysinger
2009-08-13 16:07 ` Darren Hart
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=1249298459.7460.34.camel@subratamodak.linux.ibm.com \
--to=subrata@linux.vnet.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=ltp-list@lists.sourceforge.net \
--cc=vapier@gentoo.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