From: Ben Hutchings <ben@decadent.org.uk>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: linux-mm@kvack.org, Mel Gorman <mel@csn.ul.ie>,
Johannes Weiner <jweiner@redhat.com>,
Rik van Riel <riel@redhat.com>, Hugh Dickins <hughd@google.com>
Subject: Re: sysfs interface to transparent hugepages
Date: Mon, 21 Mar 2011 13:13:03 +0000 [thread overview]
Message-ID: <1300713183.26693.343.camel@localhost> (raw)
In-Reply-To: <20110321124203.GB5719@random.random>
[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]
On Mon, 2011-03-21 at 13:42 +0100, Andrea Arcangeli wrote:
> On Mon, Mar 21, 2011 at 03:00:31AM +0000, Ben Hutchings wrote:
[...]
> > This, on the other hand, is totally ridiculous:
> >
> > if (test_bit(flag, &transparent_hugepage_flags))
> > return sprintf(buf, "[yes] no\n");
> > else
> > return sprintf(buf, "yes [no]\n");
> >
> > Why show the possible values of a boolean? I can't even find any
> > examples of 'yes' and 'no' rather than '1' and '0'.
>
> As said I like that format and I've been consistent in using it.
But not consistent with anything else in sysfs.
> If you write a parser for that format in userland it's probably easier to
> be consistent.
What if I already have some general functions like read_intr_attr(),
read_bool_attr(), etc. Should I really have to write special functions
for booleans in different parts of sysfs, depending on whether the
author liked 0/1, false/true, disabled/enabled, no/yes, or
'yes [no]'/'[yes] no'?
> Anyway this got into 2.6.38 only. For other kernels
> that shipped THP before 2.6.38 there is no
> /sys/kernel/mm/transparent_hugepage directory at all (it's renamed
> exactly to avoid any risk of sysfs ABI clashes). I doubt anybody wrote
> any parser for /sys/kernel/mm/transparent_hugepage so if this is a big
> deal I suggest you send patches to whatever you prefer.
I can do that, yes.
> Or if you tell
> me exactly how you want it, I can try to implement it and if others
> agree I don't see a problem in altering it. But others may
> disagree. Clearly best would have been if you requested a change
> during 2.6.38-rc, everyone was aware of the format as everyone has
> been twiddling with these sysfs controls. Comments welcome.
Sorry, I'm a distribution maintainer and I can't be everywhere.
> > And really, why add boolean flags for a tristate at all?
>
> I don't get the question sorry.
You have tristates {never, madvise, always} for various THM features.
Internally, these are represented as a pair of flags. They are exposed
through sysfs as tristates, but then they are also exposed as flags.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2011-03-21 13:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-21 3:00 sysfs interface to transparent hugepages Ben Hutchings
2011-03-21 12:42 ` Andrea Arcangeli
2011-03-21 13:13 ` Ben Hutchings [this message]
2011-03-21 14:08 ` Andrea Arcangeli
2011-03-21 14:25 ` Ben Hutchings
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=1300713183.26693.343.camel@localhost \
--to=ben@decadent.org.uk \
--cc=aarcange@redhat.com \
--cc=hughd@google.com \
--cc=jweiner@redhat.com \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=riel@redhat.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 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.