From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with ESMTP id 781E28D0039 for ; Sun, 20 Mar 2011 23:00:41 -0400 (EDT) From: Ben Hutchings Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-O+qF2uxBCW/A31lX6g0r" Date: Mon, 21 Mar 2011 03:00:31 +0000 Message-ID: <1300676431.26693.317.camel@localhost> Mime-Version: 1.0 Subject: sysfs interface to transparent hugepages Sender: owner-linux-mm@kvack.org List-ID: To: Andrea Arcangeli Cc: linux-mm@kvack.org --=-O+qF2uxBCW/A31lX6g0r Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This kind of cute format: if (test_bit(enabled, &transparent_hugepage_flags)) { VM_BUG_ON(test_bit(req_madv, &transparent_hugepage_flags)); return sprintf(buf, "[always] madvise never\n"); } else if (test_bit(req_madv, &transparent_hugepage_flags)) return sprintf(buf, "always [madvise] never\n"); else return sprintf(buf, "always madvise [never]\n"); is probably nice for a kernel developer or experimental user poking around in sysfs. But sysfs is mostly meant for programs to read and write, and this format is unnecessarily complex for a program to parse. Please use separate attributes for the current value and available values, like cpufreq does. I know there are other examples of the above format, but not everything already in sysfs is a *good* example! 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'. And really, why add boolean flags for a tristate at all? Ben. --=20 Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. --=-O+qF2uxBCW/A31lX6g0r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIVAwUATYa/See/yOyVhhEJAQq32BAAkIexI4kzTTknyOeu8LQ1dRiqIHBC7IPL o0DHLG/HF+ytw/s/x5y0PAYj/SbzXoZrkLC/AWjQOCCej1D7JYke4t9u0ge7GnHG QR2WoVKR+8SLw8ypCKbz0yFpZUWAPXTgsnj7dTUDXl4OgCejztnansBOXO/0gUpt gWmkOUy/ONGZUVmzyGawXMHHM2CBAwPuPA1qRH/nu8Jpthrb6useaaaF0OnAeMcS gxT82qJfVj9I8jmhcZ6tTHovUKw3zUPPm8Ls05kETzETZfsX+XT20Sfz9OG7+AG7 1N6uKdycMtyHYuAuOa2CtYfhV9yyVf7Oe5I6iEdVuX3uq/8qL2roITOQ83JrrTBw gqxgkFWs5749WSE3fiCcBch7LKNuNSxlJYGteS/m6B5KGyTTyvIVxdlCSg8ZpYAd OeLwPf4qijWbWfpWzRhIRB/xiQqfekOAqFqeh7MxGPZkU+feNiPD4I7qc845EBB0 ErF+4knYoTQLzI3BH5pQdQ/8x5yR1yMw5iScO29wMLHQi+lb9GtjdHK7pvJqf0mt Cpks+Unh6RhcnCfAz+2dEgcGS4SJeBTLaO3SIRJQ0mb7MT8q5nKDQtjWkPqhgWzS NinYY6Wpq2vwet40nlnNC9f4+Fe2KNVWuWqax+iY6mNlnenkb5nB9Ze4HOJ/k/vo WlR+r0vVfAY= =Tz/2 -----END PGP SIGNATURE----- --=-O+qF2uxBCW/A31lX6g0r-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with SMTP id 1B4738D0039 for ; Mon, 21 Mar 2011 08:42:42 -0400 (EDT) Date: Mon, 21 Mar 2011 13:42:03 +0100 From: Andrea Arcangeli Subject: Re: sysfs interface to transparent hugepages Message-ID: <20110321124203.GB5719@random.random> References: <1300676431.26693.317.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1300676431.26693.317.camel@localhost> Sender: owner-linux-mm@kvack.org List-ID: To: Ben Hutchings Cc: linux-mm@kvack.org, Mel Gorman , Johannes Weiner , Rik van Riel , Hugh Dickins On Mon, Mar 21, 2011 at 03:00:31AM +0000, Ben Hutchings wrote: > This kind of cute format: > > if (test_bit(enabled, &transparent_hugepage_flags)) { > VM_BUG_ON(test_bit(req_madv, &transparent_hugepage_flags)); > return sprintf(buf, "[always] madvise never\n"); > } else if (test_bit(req_madv, &transparent_hugepage_flags)) > return sprintf(buf, "always [madvise] never\n"); > else > return sprintf(buf, "always madvise [never]\n"); > > is probably nice for a kernel developer or experimental user poking > around in sysfs. But sysfs is mostly meant for programs to read and > write, and this format is unnecessarily complex for a program to parse. > > Please use separate attributes for the current value and available > values, like cpufreq does. I know there are other examples of the above > format, but not everything already in sysfs is a *good* example! Well I liked the io scheduler format the most as you may have guessed: noop deadline [cfq] so I used exactly that format... I didn't invent it. I found that the most intuitive and simpler so you deal with a single file, it's faster and more intuitive to use when you're on the shell and you twiddle with the values. You simply cannot get it wrong. > 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. If you write a parser for that format in userland it's probably easier to be consistent. 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. 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. > And really, why add boolean flags for a tristate at all? I don't get the question sorry. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with ESMTP id E5FA08D0039 for ; Mon, 21 Mar 2011 09:13:13 -0400 (EDT) From: Ben Hutchings In-Reply-To: <20110321124203.GB5719@random.random> References: <1300676431.26693.317.camel@localhost> <20110321124203.GB5719@random.random> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Xmo4C8URIvcaO9ZySiuW" Date: Mon, 21 Mar 2011 13:13:03 +0000 Message-ID: <1300713183.26693.343.camel@localhost> Mime-Version: 1.0 Subject: Re: sysfs interface to transparent hugepages Sender: owner-linux-mm@kvack.org List-ID: To: Andrea Arcangeli Cc: linux-mm@kvack.org, Mel Gorman , Johannes Weiner , Rik van Riel , Hugh Dickins --=-Xmo4C8URIvcaO9ZySiuW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: > >=20 > > if (test_bit(flag, &transparent_hugepage_flags)) > > return sprintf(buf, "[yes] no\n"); > > else > > return sprintf(buf, "yes [no]\n"); > >=20 > > Why show the possible values of a boolean? I can't even find any > > examples of 'yes' and 'no' rather than '1' and '0'. >=20 > 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? >=20 > 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. --=20 Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. --=-Xmo4C8URIvcaO9ZySiuW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIVAwUATYdO1Oe/yOyVhhEJAQrMOg/9G7zTw1sCLuA5mX+wDcl9DigFQhygEB0q eUl3nswkMZfbr080f/xi9NTMa8x447XU+UhYYKf+sU/DliUSXG8MvoR5zWn1upSD 09vpQrxnWLGt4I7/k2ZT6zup5l4sQ1fErEcATn/HHtB0Qpv471pPO1ygPJR1AUSg Z9FRiGCDATbpOspYq8u6DjZWl0UeiahOSgb0DIn9QPCszkE5VoPw7SMUF64xHaOd Zocst2Sb5VZs0Vr03Dmy9kmT4GHQYlZSGj2UUSdc8Fxdgsthp41kQalPA+aUqkmz TIbj0CwcpAjG25JRbGjbyBvMD8oU+kKxjTEmFb4LA16/947Zr8esS3H+0Hlg2/Sx fCxxcanDCkFp4f1xeZOt/ffJwQu+zwldsgctw2SYXzrp1RKX1OxXXEvxOpENPhFS vV7+yNTo3fiJ4+Yeg202SLKrb7qGsExSXNIAGRQuy8kYXToofX7PfExopNTLSkHf Jq0EJWUl/2TUJBUTg9dgppvU11bpqCaJLX8v/EvZb8CEEkqBW4exVkRewPWghE+H XIjXOQL5+SAI8HEbXEtEB+4S+ob5Ab5wwJ6T49PXyckK+IVCL6WDuuinav8grE9z gvvIAUljEnCskWK6MWAJCntCGWJEW7wO0W4VsNUXPrk3b0FzLoVA6ijTwIGZOCYk LfmNBoQmlVY= =l90T -----END PGP SIGNATURE----- --=-Xmo4C8URIvcaO9ZySiuW-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id 2A1A98D0039 for ; Mon, 21 Mar 2011 10:09:12 -0400 (EDT) Date: Mon, 21 Mar 2011 15:08:12 +0100 From: Andrea Arcangeli Subject: Re: sysfs interface to transparent hugepages Message-ID: <20110321140812.GD5719@random.random> References: <1300676431.26693.317.camel@localhost> <20110321124203.GB5719@random.random> <1300713183.26693.343.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1300713183.26693.343.camel@localhost> Sender: owner-linux-mm@kvack.org List-ID: To: Ben Hutchings Cc: linux-mm@kvack.org, Mel Gorman , Johannes Weiner , Rik van Riel , Hugh Dickins On Mon, Mar 21, 2011 at 01:13:03PM +0000, Ben Hutchings wrote: > 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. They must be bitflags for performance and cacheline saving reasons in the kernel (1 bitflag not enough in kernel for a userland tristate). They're more intuitive as tristate in the same file for the user to set (some combination of these flags is forbidden so exposing the flags to the user doesn't sound good idea, also considering it's an internal representation which may change, keeping the two separated is best, especially if you want your current lib not to break). There is no expectation however that you have to alter any of these settings even in server environment other than for debugging purposes: with the exception of: 1) pages_to_scan, 2) scan_sleep_millisecs 3) alloc_sleep_millisecs inside the khugepaged dir, and those three are in a format that your current sysfs lib will mangle just fine. If you've a lib that pretends to turn off THP as root, you may as well handle the cfq/deadline I/O scheduler switch in the same lib. Not really sure if your effort is worth it considering it will slightly complicate things in shell usage for debug purposes (I'd find more intuitive if also cpufreq governors were shown and selected like io schedulers). But again I'm fully neutral on issues like these as long as the patches don't break anything I'm surely fine if others like your changes. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id 2BD078D0039 for ; Mon, 21 Mar 2011 10:25:52 -0400 (EDT) From: Ben Hutchings In-Reply-To: <20110321140812.GD5719@random.random> References: <1300676431.26693.317.camel@localhost> <20110321124203.GB5719@random.random> <1300713183.26693.343.camel@localhost> <20110321140812.GD5719@random.random> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-c3uRqJOBC4EAD1sSvLWJ" Date: Mon, 21 Mar 2011 14:25:42 +0000 Message-ID: <1300717542.26693.352.camel@localhost> Mime-Version: 1.0 Subject: Re: sysfs interface to transparent hugepages Sender: owner-linux-mm@kvack.org List-ID: To: Andrea Arcangeli Cc: linux-mm@kvack.org, Mel Gorman , Johannes Weiner , Rik van Riel , Hugh Dickins --=-c3uRqJOBC4EAD1sSvLWJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-03-21 at 15:08 +0100, Andrea Arcangeli wrote: > On Mon, Mar 21, 2011 at 01:13:03PM +0000, Ben Hutchings wrote: > > 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. >=20 > They must be bitflags for performance and cacheline saving reasons in > the kernel (1 bitflag not enough in kernel for a userland > tristate). They're more intuitive as tristate in the same file for the > user to set (some combination of these flags is forbidden so exposing > the flags to the user doesn't sound good idea, also considering it's > an internal representation which may change, keeping the two separated > is best, especially if you want your current lib not to break). [...] I understand all that. However when I first looked at this I somehow thought that the tristate values were *also* exposed as flags, but I was mistaken. Sorry to bother you with this non-issue. Ben. --=20 Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. --=-c3uRqJOBC4EAD1sSvLWJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIVAwUATYdf4Oe/yOyVhhEJAQoJpA//WpUvIShbVKXUDUdL7S5ZrAplysIw70Mv GfrThf1wjBsPpPU8DTsnihRp4agW3m9nt7/UPks4jAMoz13fNioMBlzI+aVXRU4G 7VpJ7W6uVlWYeGGIG5hFy2axhSmdI6A9uPhyR8cJxSgTfXYxhu0nCv0Pest84n1d IuTmQiYojhhRac/7CZzL2ikarAAN0BWF+xiuHsZyXl9DG6VXVnlshYbeGhYi7h1k 5eJD26rDXxhZMW6A/OqLakxx9A1sECsrCm8Lcb/R8lOD41Xk8vY18VViswURqAH+ BaSSav+ZbJAMfO90QdfbZyAOEl5i/pu7tJ/J8YSKZ/wXhvkkR2izuM1wb/Dt3VDN g9+VoiU+QmdbmeaWo6yluINp+J/lu1IEB+lK5nr5wvOmkerF4MahTtS92bcs35rY k06de9osb0lrFhQCKEbw/ll9NmpkCV8SF6kIYU1qF1uxbwvtKnMzAi0vp6oSyA2E o9S1K/o1KwW3342+VeOk9OgbfAnZiPZcON6/vMdjiZVqpAYZa4Be2NpS37xKzQqS WoZ3HffW2/LBFCbMnGFnYTwOAf4prmRQ/1SlGoCUpNN0Ee1zS0gllrQTOx1N/3SS mh0/VtKH3riKovjeoqw0bVh0KoSqTDvCHZ7gLf7xFSVvox8KCOdCwlEPQhBVgTAU /RPsQ7y8bdo= =hzN1 -----END PGP SIGNATURE----- --=-c3uRqJOBC4EAD1sSvLWJ-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org