From: Han Pingtian <phan@redhat.com>
To: Garrett Cooper <yanegomi@gmail.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [PATCH v2] check two possible pathes for cpuset
Date: Wed, 23 Feb 2011 17:56:05 +0800 [thread overview]
Message-ID: <20110223095605.GI2947@hpt.nay.redhat.com> (raw)
In-Reply-To: <AANLkTi=vTXpHj92=D3O=Oua6iZjfQoaCYSokb8PZvEsi@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
On Wed, Feb 23, 2011 at 12:45:04AM -0800, Garrett Cooper wrote:
> On Mon, Feb 21, 2011 at 12:31 AM, Han Pingtian <phan@redhat.com> wrote:
> > From
> >
> > http://lxr.linux.no/#linux+v2.6.37/Documentation/cgroups/cpusets.txt
> >
> > "Note that for legacy reasons, the "cpuset" filesystem exists as a
> > wrapper around the cgroup filesystem.
> >
> > The command
> >
> > mount -t cpuset X /dev/cpuset
> >
> > is equivalent to
> >
> > mount -t cgroup -ocpuset,noprefix X /dev/cpuset"
> >
> > However, I found this is not always case. In addition, there is an
> > direct implementation without cgroup, and I can't find any doc about
> > the behaviours of the prefix.
> >
> > So, It can be difficult to predict if cpuset files have prefix or not,
> > so only to fail after checked both.
>
> Please resubmit this as a proper git-formatted email with the patch.
> Thanks,
> -Garrett
Is this one make sense to you? Thanks.
--
Han Pingtian
Quality Engineer
hpt @ #kernel-qe
Red Hat, Inc
Freedom ... courage ... Commitment ... ACCOUNTABILITY
[-- Attachment #2: 0001-check-two-possible-pathes-for-cpuset.patch --]
[-- Type: text/plain, Size: 2468 bytes --]
From ac0a3402d8e9a3d788f301818e1672a7a96596bb Mon Sep 17 00:00:00 2001
From: CAI Qian <caiqian@redhat.com>
Date: Fri, 21 Jan 2011 17:49:27 +0800
Subject: [PATCH] check two possible pathes for cpuset
From Documentation/cgroups/cpusets.txt of kernel source:
"Note that for legacy reasons, the "cpuset" filesystem exists as a
wrapper around the cgroup filesystem.
The command
mount -t cpuset X /dev/cpuset
is equivalent to
mount -t cgroup -ocpuset,noprefix X /dev/cpuset"
However, I found this is not always case. In addition, there is an
direct implementation without cgroup, and I can't find any doc about
the behaviours of the prefix.
So, It can be difficult to predict if cpuset files have prefix or not,
so only to fail after checked both.
Signed-off-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Han Pingtian <phan@redhat.com>
---
testcases/kernel/mem/lib/mem.c | 24 ++++++++++++++++++++----
1 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/testcases/kernel/mem/lib/mem.c b/testcases/kernel/mem/lib/mem.c
index 1a53359..75ecaee 100644
--- a/testcases/kernel/mem/lib/mem.c
+++ b/testcases/kernel/mem/lib/mem.c
@@ -89,16 +89,32 @@ void write_cpusets(void)
gather_cpus(cpus);
tst_resm(TINFO, "CPU list for 2nd node is %s.", cpus);
+ /* try either '/dev/cpuset/mems' or '/dev/cpuset/cpuset.mems'
+ * please see Documentation/cgroups/cpusets.txt of kernel src for detail */
fd = open(CPATH_NEW "/mems", O_WRONLY);
- if (fd == -1)
- tst_brkm(TBROK|TERRNO, cleanup, "open %s", buf);
+ if (fd == -1) {
+ if (errno == ENOENT) {
+ fd = open(CPATH_NEW "/cpuset.mems", O_WRONLY);
+ if (fd == -1)
+ tst_brkm(TBROK|TERRNO, cleanup, "open %s", buf);
+ } else
+ tst_brkm(TBROK|TERRNO, cleanup, "open %s", buf);
+ }
if (write(fd, "1", 1) != 1)
tst_brkm(TBROK|TERRNO, cleanup, "write %s", buf);
close(fd);
+ /* try either '/dev/cpuset/cpus' or '/dev/cpuset/cpuset.cpus'
+ * please see Documentation/cgroups/cpusets.txt of kernel src for detail */
fd = open(CPATH_NEW "/cpus", O_WRONLY);
- if (fd == -1)
- tst_brkm(TBROK|TERRNO, cleanup, "open %s", buf);
+ if (fd == -1) {
+ if (errno == ENOENT) {
+ fd = open(CPATH_NEW "/cpuset.cpus", O_WRONLY);
+ if (fd == -1)
+ tst_brkm(TBROK|TERRNO, cleanup, "open %s", buf);
+ } else
+ tst_brkm(TBROK|TERRNO, cleanup, "open %s", buf);
+ }
if (write(fd, cpus, strlen(cpus)) != strlen(cpus))
tst_brkm(TBROK|TERRNO, cleanup, "write %s", buf);
close(fd);
--
1.7.1
[-- Attachment #3: Type: text/plain, Size: 429 bytes --]
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
[-- Attachment #4: Type: text/plain, Size: 155 bytes --]
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2011-02-23 9:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-21 8:31 [LTP] [PATCH v2] check two possible pathes for cpuset Han Pingtian
2011-02-23 8:45 ` Garrett Cooper
2011-02-23 9:56 ` Han Pingtian [this message]
2011-02-24 5:32 ` Garrett Cooper
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=20110223095605.GI2947@hpt.nay.redhat.com \
--to=phan@redhat.com \
--cc=ltp-list@lists.sourceforge.net \
--cc=yanegomi@gmail.com \
/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