From: Jarkko Sakkinen <jarkko@kernel.org>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-sgx@vger.kernel.org,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] selftests/sgx: Trigger the reclaimer and #PF handler
Date: Fri, 9 Jul 2021 19:25:51 +0300 [thread overview]
Message-ID: <20210709162551.lqfkwusnarh7ugse@kernel.org> (raw)
In-Reply-To: <15d563b8-ad41-76c4-a645-ac5c739d6cce@intel.com>
On Wed, Jul 07, 2021 at 02:20:07PM -0700, Dave Hansen wrote:
> On 7/7/21 1:50 PM, Jarkko Sakkinen wrote:
> > There is consistent known behaviour how reclaimer and also the page fault
> > are exercised for each test. I think that is what matters most right now
> > that the basic behaviour of both the page reclaimer and page fault handler
> > gets exercised.
>
> There's also a lot of value to ensuring that tests can run _quickly_.
> If you have a test that fails one out of a million executions, it's a
> lot easier find and debug if it takes 1 ms versus 10 seconds.
>
> In other words, I think I'd prefer if we run two enclaves in each
> execution of the selftest. One can be as small as possible. The other
> can be the reclaim-triggering one.
>
> That's good both for test coverage, and it makes it a *bit* more
> straightforward to hack out the reclaim test if you need things to run
> faster.
>
> The pkeys selftest isn't a bad example here either. It has a couple of
> different "malloc()" options: THP, hugetlbfs, small-page mmap(), and a
> bunch of tests it runs on each type. As we add more SGX tests, we might
> end up with "do reclaim" just being an option we pass.
Even with large EPC's, the current test runs quite fast, because heap is
left unmeasured. It's the EEXTEND operations that would cause a major
slow-down.
I would go only to something "more complex" when the current test hits
the roof. I don't like to make code more complicated, when that does not
happen.
When there's no compatibility requirements, it's not hard to refactor it
later on.
/Jarkko
prev parent reply other threads:[~2021-07-09 16:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-05 14:36 [PATCH 0/4] selftests/sgx: Trigger the page reclaimer and #PF handler Jarkko Sakkinen
2021-07-05 14:36 ` [PATCH 1/4] x86/sgx: Add sgx_nr_all_pages to the debugfs Jarkko Sakkinen
2021-07-06 14:56 ` Dave Hansen
2021-07-06 15:39 ` Greg KH
2021-07-06 22:08 ` Jarkko Sakkinen
2021-07-05 14:36 ` [PATCH 2/4] selftests/sgx: Fix Q1 and Q2 calculation in sigstruct.c Jarkko Sakkinen
2021-07-06 20:53 ` Dave Hansen
2021-07-06 23:52 ` Jarkko Sakkinen
2021-07-05 14:36 ` [PATCH 3/4] selftests/sgx: Assign source for each segment Jarkko Sakkinen
2021-07-05 14:36 ` [PATCH 4/4] selftests/sgx: Trigger the reclaimer and #PF handler Jarkko Sakkinen
2021-07-06 18:34 ` Reinette Chatre
2021-07-06 23:50 ` Jarkko Sakkinen
2021-07-07 0:10 ` Reinette Chatre
2021-07-07 9:17 ` Jarkko Sakkinen
2021-07-07 15:02 ` Reinette Chatre
2021-07-07 20:50 ` Jarkko Sakkinen
2021-07-07 21:20 ` Reinette Chatre
2021-07-09 16:22 ` Jarkko Sakkinen
2021-07-07 21:20 ` Dave Hansen
2021-07-09 16:25 ` Jarkko Sakkinen [this message]
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=20210709162551.lqfkwusnarh7ugse@kernel.org \
--to=jarkko@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=shuah@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;
as well as URLs for NNTP newsgroup(s).