From: Greg KH <gregkh@suse.de>
To: Cliff Wickman <cpw@sgi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: [PATCH V3] x86, UV: BAU performance and error recovery
Date: Fri, 28 May 2010 17:05:26 -0700 [thread overview]
Message-ID: <20100529000526.GA30938@suse.de> (raw)
In-Reply-To: <20100528233623.GA11356@sgi.com>
On Fri, May 28, 2010 at 06:36:23PM -0500, Cliff Wickman wrote:
> /proc/sgi_uv/bau_tunables would be a read/write file to display and change
> nine threshold and delay values for tuning the BAU driver.
>
> I like debugfs, except that a distro may not build the kernel with it
> configured on. The tunables should be available as administrative
> options on a customer kernel, not just as a development tool.
All distros have debugfs turned on now, and mounted, due to the perf
interface there, as well as a lot of other good debug information that
is present.
So you don't have to worry about that.
> And in our case the distros are already building with other such writable
> options in /proc/sgi_uv. We'd like to postpone a wholesale move of such
> options (assuming there will be some better place) and stay with the existing
> location for this release.
So because some distro took a non-upstream patch, you want upstream to
accept the patch despite it being the incorrect place to put such a
file? Heh, you might want to rethink that...
> I know we (the community) would like to move non-process info out of /proc.
Yes. We also don't want new files added there that are not dealing with
processes.
> It seems to me that we need a similar filesystem for large and/or
> administrative files. That's my perspective.
I do not know of any other such "large administrative" file that needs
to be added to the system at such a time, becides this one, do you?
So please, just put it in debugfs.
thanks,
greg k-h
next prev parent reply other threads:[~2010-05-29 0:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-28 13:33 [PATCH V3] x86, UV: BAU performance and error recovery Cliff Wickman
2010-05-28 16:30 ` H. Peter Anvin
2010-05-28 16:47 ` Greg KH
2010-05-28 19:43 ` Cliff Wickman
2010-05-28 22:23 ` Greg KH
2010-05-28 23:36 ` Cliff Wickman
2010-05-29 0:05 ` Greg KH [this message]
2010-05-31 19:48 ` Cliff Wickman
2010-05-29 0:10 ` JD
2010-05-31 20:14 ` Cliff Wickman
-- strict thread matches above, loose matches on Subject: below --
2010-05-31 21:52 Cliff Wickman
2010-06-01 7:19 ` Ingo Molnar
2010-05-31 19:49 Cliff Wickman
2010-05-25 17:02 Cliff Wickman
2010-05-25 17:02 ` Cliff Wickman
2010-05-28 9:33 ` Ingo Molnar
2010-05-28 9:33 ` Ingo Molnar
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=20100529000526.GA30938@suse.de \
--to=gregkh@suse.de \
--cc=cpw@sgi.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.