From: Paul Jackson <pj@sgi.com>
To: Daniel J Blueman <daniel.blueman@gmail.com>
Cc: rdunlap@xenotime.net, linux-kernel@vger.kernel.org,
Simon.Derr@bull.net, Sylvain.Jeaugey@bull.net
Subject: Re: cpuset - question
Date: Wed, 2 Nov 2005 10:28:34 -0800 [thread overview]
Message-ID: <20051102102834.0a038576.pj@sgi.com> (raw)
In-Reply-To: <6278d2220511020935g6f88d15bp5f1e3bc692c55fe8@mail.gmail.com>
Randy asked:
> Just for info, why is this in /dev at all, instead of, say,
> /sys ??
Daniel added:
> I'm not sure of the true answer; it is likely that CPUSETS was
> designed in the 2.4 timeframe and compatibility was preferred over the
> clean sysfs interface.
No .. cpusets was a fresh design for Linux 2.6. The two primary
authors were Simon Derr of Bull and myself of SGI. So far as I
know, Bull did not have Linux 2.4 precedents. SGI had both Linux
2.4 precedents and Irix precedents. I chose not to propose either
of these SGI precedent API's for the Linux mainline kernel.
Simon proposed the primary interface for the /dev/cpuset, and I gladly
joined him as his design was superior. Simon had this file system
mounted under /proc, and Christoph Hellwig (our primary reviewer -
thanks!) objected, recommending /dev/cpuset as the mount point instead.
In Christoph's own words on May 13, 2004:
- don't mount the filesystem in procfs. the whole point of a new
fs is to move away from the procfs mess! /dev/cpuset/ sounds like
a saner mtpnt.
In any case, there are two aspects to this question. Should the
cpuset hierarchy be a separate virtual file system of its own, or part
of the sysfs file system? Then, if it is separate, where should it
be mounted.
The separate file system for the cpuset hierarchy has been a
clear success, in my (no doubt biased) view. It has its own rules
appropriate for the hierarchical cpu and node sets it is managing.
Even if we were starting this work now, I would enthusiastically
advocate having it as its own, separate file system.
Given that, the mount point becomes rather secondary in my view.
Christoph's proposal of /dev/cpuset, still seems reasonable and
adequate today.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
next prev parent reply other threads:[~2005-11-02 18:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-02 10:36 Daniel J Blueman
2005-11-02 16:26 ` Randy.Dunlap
2005-11-02 17:35 ` Daniel J Blueman
2005-11-02 18:28 ` Paul Jackson [this message]
2005-11-02 18:48 ` Randy.Dunlap
2005-11-03 8:20 ` Simon Derr
2005-11-03 8:26 ` Sylvain Jeaugey
-- strict thread matches above, loose matches on Subject: below --
2005-11-01 19:02 JaniD++
2005-11-01 20:36 ` Paul Jackson
2005-11-01 21:38 ` JaniD++
2005-11-01 22:24 ` Paul Jackson
2005-11-01 22:44 ` JaniD++
2005-11-01 23:36 ` Paul Jackson
2005-11-01 21:52 ` Bill Davidsen
2005-11-01 22:26 ` Paul Jackson
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=20051102102834.0a038576.pj@sgi.com \
--to=pj@sgi.com \
--cc=Simon.Derr@bull.net \
--cc=Sylvain.Jeaugey@bull.net \
--cc=daniel.blueman@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/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
Powered by JetHome