From: Lucas Meneghel Rodrigues <lmr@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: autotest@test.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 1/3] virt: Add Transparent Hugepages setup v2
Date: Thu, 16 Jun 2011 13:34:54 -0300 [thread overview]
Message-ID: <1308242104.2727.6.camel@justice> (raw)
In-Reply-To: <20110616155637.GZ3238@redhat.com>
On Thu, 2011-06-16 at 17:56 +0200, Andrea Arcangeli wrote:
> Hi Lucas,
Hi Andrea, thanks for the review! Yiqiao is working on the patchset, v3
or v4 will contain the fixes you have pointed out.
> > + # test_cfg holds all the desired host config values we want to set
> > + # before THP tests
> > + test_cfg={"%s/defrag" % self.thp_path: "yes",
>
> upstream >=3.0.0 this would value would be 1 (on 2.6.38 it's still "yes").
>
> > + "%s/enabled" % self.thp_path: "always",
> > + "%s/khugepaged/defrag" % self.thp_path: "yes",
>
> Upstream >=3.0.0 it's 1.
Ok, we'll set the values conditionally depending on the running kernel
version.
> > + "%s/khugepaged/scan_sleep_millisecs" % self.thp_path: "100",
>
> So this is meant to increase khugepaged scan rate compared to the
> default.
Yep.
> > + "%s/khugepaged/pages_to_scan" % self.thp_path: "4096",
> > + "%s/khugepaged/alloc_sleep_millisecs" % self.thp_path: "100",
>
> An allocation failure is not very likely and it's generally better to
> keep this bigger than the scan_sleep_millisecs. I would keep a factor
> of 6 of difference, so you could set it to 600 if scan_sleep_millisecs
> is set to 100.
Ok, will do.
> > + "/sys/kernel/mm/ksm/run": "1",
> > + "/proc/sys/vm/nr_hugepages":"0"}
>
> nr_hugepages is unlikely to matter.
Dropping this then.
> > + if os.path.isfile("%s/khugepaged/enabled" % self.thp_path):
> > + test_cfg["%s/khugepaged/enabled" % self.thp_path] = "always"
> > + if os.path.isfile("%s/khugepaged/max_ptes_none" % self.thp_path):
> > + test_cfg["%s/khugepaged/max_ptes_none" % self.thp_path] = "511"
> > + test_cfg["%s/defrag" % self.thp_path] = "always"
> > +
> > + tmp_list = []
> > + test_config = self.params.get("test_config", None)
> > + if test_config is not None:
> > + tmp_list = re.split(';', test_config)
> > + while len(tmp_list) > 0:
> > + tmp_cfg = tmp_list.pop()
> > + test_cfg[re.split(":", tmp_cfg)[0]] = sre.split(":", tmp_cfg)[1]
> > +
> > + self.original_config = {}
> > + # Save host current config, so we can restore it during cleanup
> > + for path in test_cfg:
> > + param = open(path, 'r').read()
> > + if ("enabled" in param) or ("defrag" in param):
> > + param = re.split("\[|\]", param)[1] + '\n'
> > + self.original_config[path] = param
> > +
> > + self.test_config = test_cfg
> > +
> > +
> > + def set_env(self):
> > + """
> > + Applies test configuration on the host.
> > + """
> > + if self.test_config:
> > + for path in self.test_config.keys():
> > + file(path, 'w').write(self.test_config[path])
> > +
> > +
> > + def set_params(self, path_dict={}, filename="", value=""):
> > + """
> > + Sets the value of a config file for a given path.
> > +
> > + @param path_dict: Dict of files' paths {path : value}
> > + @param filename: Name of file to setup
> > + @param value: Value set to the configuration files
> > + """
> > + for path in path_dict.keys():
> > + if path in filename:
> > + try:
> > + file(path, "w").write(value)
> > + except IOError, e:
> > + raise THPWriteConfigError("Can not set %s to %s: %s" %
> > + (value, filename, e))
> > +
> > +
> > + def khugepaged_test(self):
> > + """
> > + Start, stop and frequency change test for khugepaged.
> > + """
> > + status_list = ["never", "always", "never"]
> > + for status in status_list:
> > + self.set_params(self.test_config, "enabled", status)
> > + try:
> > + utils.run('pgrep khugepaged')
> > + except error.CmdError:
> > + raise THPKhugepagedError("khugepaged can not be set to "
> > + "status %s" % status)
>
> khugepaged will quit when enabled is set to never, but it's not a bug
> (it's to save the memory of the kernel thread stack when THP is
> disabled). So I'm unsure if the pgrep is going to create spurious errors.
Ok, will improve this check then, based on the expected behavior.
next prev parent reply other threads:[~2011-06-16 16:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-16 0:18 [PATCH 0/3] Transparent Hugepages test v2 Lucas Meneghel Rodrigues
2011-06-16 0:18 ` [PATCH 1/3] virt: Add Transparent Hugepages setup v2 Lucas Meneghel Rodrigues
2011-06-16 15:56 ` Andrea Arcangeli
2011-06-16 16:34 ` Lucas Meneghel Rodrigues [this message]
2011-06-17 8:21 ` Andrea Arcangeli
2011-06-16 0:18 ` [PATCH 2/3] KVM test: Add Transparent Hugepages subtests v2 Lucas Meneghel Rodrigues
2011-06-16 0:18 ` [PATCH 3/3] Add THP test variants to tests_base.cfg.sample v2 Lucas Meneghel Rodrigues
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=1308242104.2727.6.camel@justice \
--to=lmr@redhat.com \
--cc=aarcange@redhat.com \
--cc=autotest@test.kernel.org \
--cc=kvm@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