Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1210289 > unrolled thread

[PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status

Started byNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
First post2015-08-20 10:50 +0200
Last post2015-08-31 11:20 +0200
Articles 16 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2015-08-20 10:50 +0200
    Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Michal Hocko <mhocko@kernel.org> - 2015-08-20 13:10 +0200
      Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status David Rientjes <rientjes@google.com> - 2015-08-20 22:00 +0200
        Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Michal Hocko <mhocko@kernel.org> - 2015-08-21 08:40 +0200
          Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Jörn Engel <joern@purestorage.com> - 2015-08-21 18:40 +0200
      Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> - 2015-08-21 01:40 +0200
        Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Michal Hocko <mhocko@kernel.org> - 2015-08-21 09:00 +0200
          Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Jörn Engel <joern@purestorage.com> - 2015-08-21 18:40 +0200
            Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Michal Hocko <mhocko@kernel.org> - 2015-08-24 11:00 +0200
              Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status David Rientjes <rientjes@google.com> - 2015-08-26 01:30 +0200
                Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Michal Hocko <mhocko@kernel.org> - 2015-08-26 08:40 +0200
                  Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status David Rientjes <rientjes@google.com> - 2015-08-27 00:10 +0200
                    Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Michal Hocko <mhocko@kernel.org> - 2015-08-27 08:50 +0200
                      Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Jörn Engel <joern@purestorage.com> - 2015-08-27 19:30 +0200
                        Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status David Rientjes <rientjes@google.com> - 2015-08-27 22:50 +0200
                        Re: [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to  /proc/PID/status Michal Hocko <mhocko@kernel.org> - 2015-08-31 11:20 +0200

#1210289 — [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status

FromNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date2015-08-20 10:50 +0200
Subject[PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status
Message-ID<pZtHQ-8aH-13@gated-at.bofh.it>
Q3VycmVudGx5IHRoZXJlJ3Mgbm8gZWFzeSB3YXkgdG8gZ2V0IHBlci1wcm9jZXNzIHVzYWdlIG9m
IGh1Z2V0bGIgcGFnZXMsIHdoaWNoDQppcyBpbmNvbnZlbmllbnQgYmVjYXVzZSB1c2Vyc3BhY2Ug
YXBwbGljYXRpb25zIHdoaWNoIHVzZSBodWdldGxiIHR5cGljYWxseSB3YW50DQp0byBjb250cm9s
IHRoZWlyIHByb2Nlc3NlcyBvbiB0aGUgYmFzaXMgb2YgaG93IG11Y2ggbWVtb3J5IChpbmNsdWRp
bmcgaHVnZXRsYikNCnRoZXkgdXNlLiBTbyB0aGlzIHBhdGNoIHNpbXBseSBwcm92aWRlcyBlYXN5
IGFjY2VzcyB0byB0aGUgaW5mbyB2aWENCi9wcm9jL1BJRC9zdGF0dXMuDQoNCldpdGggdGhpcyBw
YXRjaCwgZm9yIGV4YW1wbGUsIC9wcm9jL1BJRC9zdGF0dXMgc2hvd3MgYSBsaW5lIGxpa2UgdGhp
czoNCg0KICBIdWdldGxiUGFnZXM6ICAgICAgMjA0ODAga0IgKDEwKjIwNDhrQikNCg0KSWYgeW91
ciBzeXN0ZW0gc3VwcG9ydHMgYW5kIGVuYWJsZXMgbXVsdGlwbGUgaHVnZXBhZ2Ugc2l6ZXMsIHRo
ZSBsaW5lIGxvb2tzDQpsaWtlIHRoaXM6DQoNCiAgSHVnZXRsYlBhZ2VzOiAgICAxMDY5MDU2IGtC
ICgxKjEwNDg1NzZrQiAxMCoyMDQ4a0IpDQoNCiwgc28geW91IGNhbiBlYXNpbHkga25vdyBob3cg
bWFueSBodWdlcGFnZXMgaW4gd2hpY2ggcGFnZXNpemUgYXJlIHVzZWQgYnkgYQ0KcHJvY2Vzcy4N
Cg0KU2lnbmVkLW9mZi1ieTogTmFveWEgSG9yaWd1Y2hpIDxuLWhvcmlndWNoaUBhaC5qcC5uZWMu
Y29tPg0KQWNrZWQtYnk6IEpvZXJuIEVuZ2VsIDxqb2VybkBsb2dmcy5vcmc+DQpBY2tlZC1ieTog
RGF2aWQgUmllbnRqZXMgPHJpZW50amVzQGdvb2dsZS5jb20+DQotLS0NCnY0IC0+IHY1Og0KLSBh
ZGQgKHN0cnVjdCBodWdldGxiX3VzYWdlICopIHRvIHN0cnVjdCBtbV9zdHJ1Y3QNCi0gdXNlICVs
dSBpbnN0ZWFkIG9mICVkIGZvciBzZXFfcHJpbnRmKCkNCi0gaW50cm9kdWNlIGh1Z2V0bGJfZm9y
aw0KDQp2MyAtPiB2NDoNCi0gcmVuYW1lIGZpZWxkIChWbUh1Z2V0bGJSU1MgaXMgbm90IHRoZSBi
ZXN0IG5hbWUpDQotIGludHJvZHVjZSBzdHJ1Y3QgaHVnZXRsYl91c2FnZSBpbiBzdHJ1Y3QgbW1f
c3RydWN0IChubyBpbnZhc2lvbiB0byBzdHJ1Y3QNCiAgbW1fcnNzX3N0YXQpDQotIGludHJvZHVj
ZSBodWdldGxiX3JlcG9ydF91c2FnZSgpDQotIG1lcmdlZCBkb2N1bWVudGF0aW9uIHVwZGF0ZQ0K
DQp2MiAtPiB2MzoNCi0gdXNlIGlubGluZSBmdW5jdGlvbnMgaW5zdGVhZCBvZiBtYWNyb3MgZm9y
ICFDT05GSUdfSFVHRVRMQl9QQUdFDQotLS0NCiBEb2N1bWVudGF0aW9uL2ZpbGVzeXN0ZW1zL3By
b2MudHh0IHwgIDMgKysrDQogZnMvaHVnZXRsYmZzL2lub2RlLmMgICAgICAgICAgICAgICB8IDEy
ICsrKysrKysrKysNCiBmcy9wcm9jL3Rhc2tfbW11LmMgICAgICAgICAgICAgICAgIHwgIDEgKw0K
IGluY2x1ZGUvbGludXgvaHVnZXRsYi5oICAgICAgICAgICAgfCAzNiArKysrKysrKysrKysrKysr
KysrKysrKysrKysrKw0KIGluY2x1ZGUvbGludXgvbW1fdHlwZXMuaCAgICAgICAgICAgfCAgNyAr
KysrKysNCiBrZXJuZWwvZm9yay5jICAgICAgICAgICAgICAgICAgICAgIHwgIDMgKysrDQogbW0v
aHVnZXRsYi5jICAgICAgICAgICAgICAgICAgICAgICB8IDQ2ICsrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrDQogbW0vbW1hcC5jICAgICAgICAgICAgICAgICAgICAgICAgICB8
ICAxICsNCiBtbS9ybWFwLmMgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIDQgKysrLQ0KIDkg
ZmlsZXMgY2hhbmdlZCwgMTEyIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCg0KZGlmZiAt
LWdpdCB2NC4yLXJjNC9Eb2N1bWVudGF0aW9uL2ZpbGVzeXN0ZW1zL3Byb2MudHh0IHY0LjItcmM0
X3BhdGNoZWQvRG9jdW1lbnRhdGlvbi9maWxlc3lzdGVtcy9wcm9jLnR4dA0KaW5kZXggMjJlNDAy
MTFlZjY0Li5mNTYxZmM0NmU0MWIgMTAwNjQ0DQotLS0gdjQuMi1yYzQvRG9jdW1lbnRhdGlvbi9m
aWxlc3lzdGVtcy9wcm9jLnR4dA0KKysrIHY0LjItcmM0X3BhdGNoZWQvRG9jdW1lbnRhdGlvbi9m
aWxlc3lzdGVtcy9wcm9jLnR4dA0KQEAgLTE3NCw2ICsxNzQsNyBAQCBGb3IgZXhhbXBsZSwgdG8g
Z2V0IHRoZSBzdGF0dXMgaW5mb3JtYXRpb24gb2YgYSBwcm9jZXNzLCBhbGwgeW91IGhhdmUgdG8g
ZG8gaXMNCiAgIFZtTGliOiAgICAgIDE0MTIga0INCiAgIFZtUFRFOiAgICAgICAgMjAga2INCiAg
IFZtU3dhcDogICAgICAgIDAga0INCisgIEh1Z2V0bGJQYWdlczogICAgICAgICAgMCBrQiAoMCoy
MDQ4a0IpDQogICBUaHJlYWRzOiAgICAgICAgMQ0KICAgU2lnUTogICAwLzI4NTc4DQogICBTaWdQ
bmQ6IDAwMDAwMDAwMDAwMDAwMDANCkBAIC0yMzcsNiArMjM4LDggQEAgVGFibGUgMS0yOiBDb250
ZW50cyBvZiB0aGUgc3RhdHVzIGZpbGVzIChhcyBvZiA0LjEpDQogIFZtUFRFICAgICAgICAgICAg
ICAgICAgICAgICBzaXplIG9mIHBhZ2UgdGFibGUgZW50cmllcw0KICBWbVBNRCAgICAgICAgICAg
ICAgICAgICAgICAgc2l6ZSBvZiBzZWNvbmQgbGV2ZWwgcGFnZSB0YWJsZXMNCiAgVm1Td2FwICAg
ICAgICAgICAgICAgICAgICAgIHNpemUgb2Ygc3dhcCB1c2FnZSAodGhlIG51bWJlciBvZiByZWZl
cnJlZCBzd2FwZW50cykNCisgSHVnZXRsYlBhZ2VzICAgICAgICAgICAgICAgIHNpemUgb2YgaHVn
ZXRsYiBtZW1vcnkgcG9ydGlvbnMgKHdpdGggYWRkaXRpb25hbCBpbmZvDQorICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBhYm91dCBudW1iZXIgb2YgbWFwcGVkIGh1Z2VwYWdlcyBmb3IgZWFj
aCBwYWdlIHNpemUpDQogIFRocmVhZHMgICAgICAgICAgICAgICAgICAgICBudW1iZXIgb2YgdGhy
ZWFkcw0KICBTaWdRICAgICAgICAgICAgICAgICAgICAgICAgbnVtYmVyIG9mIHNpZ25hbHMgcXVl
dWVkL21heC4gbnVtYmVyIGZvciBxdWV1ZQ0KICBTaWdQbmQgICAgICAgICAgICAgICAgICAgICAg
Yml0bWFwIG9mIHBlbmRpbmcgc2lnbmFscyBmb3IgdGhlIHRocmVhZA0KZGlmZiAtLWdpdCB2NC4y
LXJjNC9mcy9odWdldGxiZnMvaW5vZGUuYyB2NC4yLXJjNF9wYXRjaGVkL2ZzL2h1Z2V0bGJmcy9p
bm9kZS5jDQppbmRleCAwY2Y3NGRmNjg2MTcuLmJmNmVhMjY0NWQzNSAxMDA2NDQNCi0tLSB2NC4y
LXJjNC9mcy9odWdldGxiZnMvaW5vZGUuYw0KKysrIHY0LjItcmM0X3BhdGNoZWQvZnMvaHVnZXRs
YmZzL2lub2RlLmMNCkBAIC0xMTUsNiArMTE1LDEzIEBAIHN0YXRpYyBpbnQgaHVnZXRsYmZzX2Zp
bGVfbW1hcChzdHJ1Y3QgZmlsZSAqZmlsZSwgc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEpDQog
CWlmICh2bWEtPnZtX3Bnb2ZmICYgKH5odWdlX3BhZ2VfbWFzayhoKSA+PiBQQUdFX1NISUZUKSkN
CiAJCXJldHVybiAtRUlOVkFMOw0KIA0KKwlpZiAoIXZtYS0+dm1fbW0tPmh1Z2V0bGJfdXNhZ2Up
IHsNCisJCXZtYS0+dm1fbW0tPmh1Z2V0bGJfdXNhZ2UgPSBremFsbG9jKHNpemVvZihzdHJ1Y3Qg
aHVnZXRsYl91c2FnZSksDQorCQkJCQkJCUdGUF9LRVJORUwpOw0KKwkJaWYgKCF2bWEtPnZtX21t
LT5odWdldGxiX3VzYWdlKQ0KKwkJCXJldHVybiAtRU5PTUVNOw0KKwl9DQorDQogCXZtYV9sZW4g
PSAobG9mZl90KSh2bWEtPnZtX2VuZCAtIHZtYS0+dm1fc3RhcnQpOw0KIA0KIAltdXRleF9sb2Nr
KCZpbm9kZS0+aV9tdXRleCk7DQpAQCAtMTM4LDYgKzE0NSwxMSBAQCBzdGF0aWMgaW50IGh1Z2V0
bGJmc19maWxlX21tYXAoc3RydWN0IGZpbGUgKmZpbGUsIHN0cnVjdCB2bV9hcmVhX3N0cnVjdCAq
dm1hKQ0KIAlyZXR1cm4gcmV0Ow0KIH0NCiANCit2b2lkIGV4aXRfaHVnZXRsYl9tbWFwKHN0cnVj
dCBtbV9zdHJ1Y3QgKm1tKQ0KK3sNCisJa2ZyZWUobW0tPmh1Z2V0bGJfdXNhZ2UpOw0KK30NCisN
CiAvKg0KICAqIENhbGxlZCB1bmRlciBkb3duX3dyaXRlKG1tYXBfc2VtKS4NCiAgKi8NCmRpZmYg
LS1naXQgdjQuMi1yYzQvZnMvcHJvYy90YXNrX21tdS5jIHY0LjItcmM0X3BhdGNoZWQvZnMvcHJv
Yy90YXNrX21tdS5jDQppbmRleCAyYzM3OTM4YjgyZWUuLmIzY2Y3ZmE5ZWY2YyAxMDA2NDQNCi0t
LSB2NC4yLXJjNC9mcy9wcm9jL3Rhc2tfbW11LmMNCisrKyB2NC4yLXJjNF9wYXRjaGVkL2ZzL3By
b2MvdGFza19tbXUuYw0KQEAgLTY5LDYgKzY5LDcgQEAgdm9pZCB0YXNrX21lbShzdHJ1Y3Qgc2Vx
X2ZpbGUgKm0sIHN0cnVjdCBtbV9zdHJ1Y3QgKm1tKQ0KIAkJcHRlcyA+PiAxMCwNCiAJCXBtZHMg
Pj4gMTAsDQogCQlzd2FwIDw8IChQQUdFX1NISUZULTEwKSk7DQorCWh1Z2V0bGJfcmVwb3J0X3Vz
YWdlKG0sIG1tKTsNCiB9DQogDQogdW5zaWduZWQgbG9uZyB0YXNrX3ZzaXplKHN0cnVjdCBtbV9z
dHJ1Y3QgKm1tKQ0KZGlmZiAtLWdpdCB2NC4yLXJjNC9pbmNsdWRlL2xpbnV4L2h1Z2V0bGIuaCB2
NC4yLXJjNF9wYXRjaGVkL2luY2x1ZGUvbGludXgvaHVnZXRsYi5oDQppbmRleCBkODkxZjk0OTQ2
NmEuLmRiNjQyYWQwYjg0NyAxMDA2NDQNCi0tLSB2NC4yLXJjNC9pbmNsdWRlL2xpbnV4L2h1Z2V0
bGIuaA0KKysrIHY0LjItcmM0X3BhdGNoZWQvaW5jbHVkZS9saW51eC9odWdldGxiLmgNCkBAIC00
NjksNiArNDY5LDI1IEBAIHN0YXRpYyBpbmxpbmUgc3BpbmxvY2tfdCAqaHVnZV9wdGVfbG9ja3B0
cihzdHJ1Y3QgaHN0YXRlICpoLA0KICNkZWZpbmUgaHVnZXBhZ2VzX3N1cHBvcnRlZCgpIChIUEFH
RV9TSElGVCAhPSAwKQ0KICNlbmRpZg0KIA0KK3N0cnVjdCBodWdldGxiX3VzYWdlIHsNCisJYXRv
bWljX2xvbmdfdCBjb3VudFtIVUdFX01BWF9IU1RBVEVdOw0KK307DQorDQordm9pZCBodWdldGxi
X3JlcG9ydF91c2FnZShzdHJ1Y3Qgc2VxX2ZpbGUgKm0sIHN0cnVjdCBtbV9zdHJ1Y3QgKm1tKTsN
Cit2b2lkIGV4aXRfaHVnZXRsYl9tbWFwKHN0cnVjdCBtbV9zdHJ1Y3QgKm1tKTsNCitpbnQgaHVn
ZXRsYl9mb3JrKHN0cnVjdCBtbV9zdHJ1Y3QgKm5ldywgc3RydWN0IG1tX3N0cnVjdCAqb2xkKTsN
CisNCitzdGF0aWMgaW5saW5lIHZvaWQgaW5jX2h1Z2V0bGJfY291bnQoc3RydWN0IG1tX3N0cnVj
dCAqbW0sIHN0cnVjdCBoc3RhdGUgKmgpDQorew0KKwlWTV9CVUdfT05fTU0oIW1tLT5odWdldGxi
X3VzYWdlLCBtbSk7DQorCWF0b21pY19sb25nX2luYygmbW0tPmh1Z2V0bGJfdXNhZ2UtPmNvdW50
W2hzdGF0ZV9pbmRleChoKV0pOw0KK30NCisNCitzdGF0aWMgaW5saW5lIHZvaWQgZGVjX2h1Z2V0
bGJfY291bnQoc3RydWN0IG1tX3N0cnVjdCAqbW0sIHN0cnVjdCBoc3RhdGUgKmgpDQorew0KKwlW
TV9CVUdfT05fTU0oIW1tLT5odWdldGxiX3VzYWdlLCBtbSk7DQorCWF0b21pY19sb25nX2RlYygm
bW0tPmh1Z2V0bGJfdXNhZ2UtPmNvdW50W2hzdGF0ZV9pbmRleChoKV0pOw0KK30NCiAjZWxzZQkv
KiBDT05GSUdfSFVHRVRMQl9QQUdFICovDQogc3RydWN0IGhzdGF0ZSB7fTsNCiAjZGVmaW5lIGFs
bG9jX2h1Z2VfcGFnZV9ub2RlKGgsIG5pZCkgTlVMTA0KQEAgLTUwNCw2ICs1MjMsMjMgQEAgc3Rh
dGljIGlubGluZSBzcGlubG9ja190ICpodWdlX3B0ZV9sb2NrcHRyKHN0cnVjdCBoc3RhdGUgKmgs
DQogew0KIAlyZXR1cm4gJm1tLT5wYWdlX3RhYmxlX2xvY2s7DQogfQ0KKw0KK3N0YXRpYyBpbmxp
bmUgdm9pZCBodWdldGxiX3JlcG9ydF91c2FnZShzdHJ1Y3Qgc2VxX2ZpbGUgKmYsIHN0cnVjdCBt
bV9zdHJ1Y3QgKm0pDQorew0KK30NCisNCitzdGF0aWMgaW5saW5lIHZvaWQgZXhpdF9odWdldGxi
X21tYXAoc3RydWN0IG1tX3N0cnVjdCAqbW0pDQorew0KK30NCisNCitzdGF0aWMgaW5saW5lIGlu
dCBodWdldGxiX2Zvcmsoc3RydWN0IG1tX3N0cnVjdCAqbmV3LCBzdHJ1Y3QgbW1fc3RydWN0ICpv
bGQpDQorew0KKwlyZXR1cm4gMDsNCit9DQorDQorc3RhdGljIGlubGluZSB2b2lkIGRlY19odWdl
dGxiX2NvdW50KHN0cnVjdCBtbV9zdHJ1Y3QgKm1tLCBzdHJ1Y3QgaHN0YXRlICpoKQ0KK3sNCit9
DQogI2VuZGlmCS8qIENPTkZJR19IVUdFVExCX1BBR0UgKi8NCiANCiBzdGF0aWMgaW5saW5lIHNw
aW5sb2NrX3QgKmh1Z2VfcHRlX2xvY2soc3RydWN0IGhzdGF0ZSAqaCwNCmRpZmYgLS1naXQgdjQu
Mi1yYzQvaW5jbHVkZS9saW51eC9tbV90eXBlcy5oIHY0LjItcmM0X3BhdGNoZWQvaW5jbHVkZS9s
aW51eC9tbV90eXBlcy5oDQppbmRleCAwMDM4YWM3NDY2ZmQuLjg1MWU5NjRlZThkNiAxMDA2NDQN
Ci0tLSB2NC4yLXJjNC9pbmNsdWRlL2xpbnV4L21tX3R5cGVzLmgNCisrKyB2NC4yLXJjNF9wYXRj
aGVkL2luY2x1ZGUvbGludXgvbW1fdHlwZXMuaA0KQEAgLTM2NCw2ICszNjQsMTAgQEAgc3RydWN0
IG1tX3Jzc19zdGF0IHsNCiAJYXRvbWljX2xvbmdfdCBjb3VudFtOUl9NTV9DT1VOVEVSU107DQog
fTsNCiANCisjaWZkZWYgQ09ORklHX0hVR0VUTEJfUEFHRQ0KK3N0cnVjdCBodWdldGxiX3VzYWdl
Ow0KKyNlbmRpZg0KKw0KIHN0cnVjdCBraW9jdHhfdGFibGU7DQogc3RydWN0IG1tX3N0cnVjdCB7
DQogCXN0cnVjdCB2bV9hcmVhX3N0cnVjdCAqbW1hcDsJCS8qIGxpc3Qgb2YgVk1BcyAqLw0KQEAg
LTQ4NCw2ICs0ODgsOSBAQCBzdHJ1Y3QgbW1fc3RydWN0IHsNCiAJLyogYWRkcmVzcyBvZiB0aGUg
Ym91bmRzIGRpcmVjdG9yeSAqLw0KIAl2b2lkIF9fdXNlciAqYmRfYWRkcjsNCiAjZW5kaWYNCisj
aWZkZWYgQ09ORklHX0hVR0VUTEJfUEFHRQ0KKwlzdHJ1Y3QgaHVnZXRsYl91c2FnZSAqaHVnZXRs
Yl91c2FnZTsNCisjZW5kaWYNCiB9Ow0KIA0KIHN0YXRpYyBpbmxpbmUgdm9pZCBtbV9pbml0X2Nw
dW1hc2soc3RydWN0IG1tX3N0cnVjdCAqbW0pDQpkaWZmIC0tZ2l0IHY0LjItcmM0L2tlcm5lbC9m
b3JrLmMgdjQuMi1yYzRfcGF0Y2hlZC9rZXJuZWwvZm9yay5jDQppbmRleCBkYmQ5YjhkN2I3Y2Mu
LmQ0M2JhYTkxZDQ4YyAxMDA2NDQNCi0tLSB2NC4yLXJjNC9rZXJuZWwvZm9yay5jDQorKysgdjQu
Mi1yYzRfcGF0Y2hlZC9rZXJuZWwvZm9yay5jDQpAQCAtNDI1LDYgKzQyNSw5IEBAIHN0YXRpYyBp
bnQgZHVwX21tYXAoc3RydWN0IG1tX3N0cnVjdCAqbW0sIHN0cnVjdCBtbV9zdHJ1Y3QgKm9sZG1t
KQ0KIAlyZXR2YWwgPSBraHVnZXBhZ2VkX2ZvcmsobW0sIG9sZG1tKTsNCiAJaWYgKHJldHZhbCkN
CiAJCWdvdG8gb3V0Ow0KKwlyZXR2YWwgPSBodWdldGxiX2ZvcmsobW0sIG9sZG1tKTsNCisJaWYg
KHJldHZhbCkNCisJCWdvdG8gb3V0Ow0KIA0KIAlwcmV2ID0gTlVMTDsNCiAJZm9yIChtcG50ID0g
b2xkbW0tPm1tYXA7IG1wbnQ7IG1wbnQgPSBtcG50LT52bV9uZXh0KSB7DQpkaWZmIC0tZ2l0IHY0
LjItcmM0L21tL2h1Z2V0bGIuYyB2NC4yLXJjNF9wYXRjaGVkL21tL2h1Z2V0bGIuYw0KaW5kZXgg
YThjMzA4NzA4OWQ4Li4zYWE4Yzc5MTkzNjQgMTAwNjQ0DQotLS0gdjQuMi1yYzQvbW0vaHVnZXRs
Yi5jDQorKysgdjQuMi1yYzRfcGF0Y2hlZC9tbS9odWdldGxiLmMNCkBAIC0yNTYyLDYgKzI1NjIs
NDkgQEAgdm9pZCBodWdldGxiX3Nob3dfbWVtaW5mbyh2b2lkKQ0KIAkJCQkxVUwgPDwgKGh1Z2Vf
cGFnZV9vcmRlcihoKSArIFBBR0VfU0hJRlQgLSAxMCkpOw0KIH0NCiANCitzdGF0aWMgdW5zaWdu
ZWQgbG9uZyBtbV9oc3RhdGVfdXNhZ2Uoc3RydWN0IG1tX3N0cnVjdCAqbW0sIGludCBoc19pZHgp
DQorew0KKwlpZiAoIW1tLT5odWdldGxiX3VzYWdlKQ0KKwkJcmV0dXJuIDA7DQorCXJldHVybiBh
dG9taWNfbG9uZ19yZWFkKCZtbS0+aHVnZXRsYl91c2FnZS0+Y291bnRbaHNfaWR4XSk7DQorfQ0K
Kw0KK3ZvaWQgaHVnZXRsYl9yZXBvcnRfdXNhZ2Uoc3RydWN0IHNlcV9maWxlICptLCBzdHJ1Y3Qg
bW1fc3RydWN0ICptbSkNCit7DQorCWludCBpOw0KKwl1bnNpZ25lZCBsb25nIHRvdGFsX3VzYWdl
ID0gMDsNCisNCisJZm9yIChpID0gMDsgaSA8IEhVR0VfTUFYX0hTVEFURTsgaSsrKSB7DQorCQl0
b3RhbF91c2FnZSArPSBtbV9oc3RhdGVfdXNhZ2UobW0sIGkpICoNCisJCQkoaHVnZV9wYWdlX3Np
emUoJmhzdGF0ZXNbaV0pID4+IDEwKTsNCisJfQ0KKw0KKwlzZXFfcHJpbnRmKG0sICJIdWdldGxi
UGFnZXM6XHQlOGx1IGtCICgiLCB0b3RhbF91c2FnZSk7DQorCWZvciAoaSA9IDA7IGkgPCBIVUdF
X01BWF9IU1RBVEU7IGkrKykgew0KKwkJaWYgKGh1Z2VfcGFnZV9vcmRlcigmaHN0YXRlc1tpXSkg
PT0gMCkNCisJCQlicmVhazsNCisJCWlmIChpID4gMCkNCisJCQlzZXFfcHV0cyhtLCAiICIpOw0K
Kw0KKwkJc2VxX3ByaW50ZihtLCAiJWxkKiVsdWtCIiwgbW1faHN0YXRlX3VzYWdlKG1tLCBpKSwN
CisJCQlodWdlX3BhZ2Vfc2l6ZSgmaHN0YXRlc1tpXSkgPj4gMTApOw0KKwl9DQorCXNlcV9wdXRz
KG0sICIpXG4iKTsNCit9DQorDQoraW50IGh1Z2V0bGJfZm9yayhzdHJ1Y3QgbW1fc3RydWN0ICpu
ZXcsIHN0cnVjdCBtbV9zdHJ1Y3QgKm9sZCkNCit7DQorCWlmIChvbGQtPmh1Z2V0bGJfdXNhZ2Up
IHsNCisJCW5ldy0+aHVnZXRsYl91c2FnZSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBodWdldGxi
X3VzYWdlKSwNCisJCQkJCQkJR0ZQX0tFUk5FTCk7DQorCQlpZiAoIW5ldy0+aHVnZXRsYl91c2Fn
ZSkNCisJCQlyZXR1cm4gLUVOT01FTTsNCisJCW1lbWNweShuZXctPmh1Z2V0bGJfdXNhZ2UsIG9s
ZC0+aHVnZXRsYl91c2FnZSwNCisJCQlzaXplb2Yoc3RydWN0IGh1Z2V0bGJfdXNhZ2UpKTsNCisJ
fQ0KKwlyZXR1cm4gMDsNCit9DQorDQogLyogUmV0dXJuIHRoZSBudW1iZXIgcGFnZXMgb2YgbWVt
b3J5IHdlIHBoeXNpY2FsbHkgaGF2ZSwgaW4gUEFHRV9TSVpFIHVuaXRzLiAqLw0KIHVuc2lnbmVk
IGxvbmcgaHVnZXRsYl90b3RhbF9wYWdlcyh2b2lkKQ0KIHsNCkBAIC0yNzk3LDYgKzI4NDAsNyBA
QCBpbnQgY29weV9odWdldGxiX3BhZ2VfcmFuZ2Uoc3RydWN0IG1tX3N0cnVjdCAqZHN0LCBzdHJ1
Y3QgbW1fc3RydWN0ICpzcmMsDQogCQkJZ2V0X3BhZ2UocHRlcGFnZSk7DQogCQkJcGFnZV9kdXBf
cm1hcChwdGVwYWdlKTsNCiAJCQlzZXRfaHVnZV9wdGVfYXQoZHN0LCBhZGRyLCBkc3RfcHRlLCBl
bnRyeSk7DQorCQkJaW5jX2h1Z2V0bGJfY291bnQoZHN0LCBoKTsNCiAJCX0NCiAJCXNwaW5fdW5s
b2NrKHNyY19wdGwpOw0KIAkJc3Bpbl91bmxvY2soZHN0X3B0bCk7DQpAQCAtMjg3Nyw2ICsyOTIx
LDcgQEAgdm9pZCBfX3VubWFwX2h1Z2VwYWdlX3JhbmdlKHN0cnVjdCBtbXVfZ2F0aGVyICp0bGIs
IHN0cnVjdCB2bV9hcmVhX3N0cnVjdCAqdm1hLA0KIAkJaWYgKGh1Z2VfcHRlX2RpcnR5KHB0ZSkp
DQogCQkJc2V0X3BhZ2VfZGlydHkocGFnZSk7DQogDQorCQlkZWNfaHVnZXRsYl9jb3VudChtbSwg
aCk7DQogCQlwYWdlX3JlbW92ZV9ybWFwKHBhZ2UpOw0KIAkJZm9yY2VfZmx1c2ggPSAhX190bGJf
cmVtb3ZlX3BhZ2UodGxiLCBwYWdlKTsNCiAJCWlmIChmb3JjZV9mbHVzaCkgew0KQEAgLTMyNjEs
NiArMzMwNiw3IEBAIHN0YXRpYyBpbnQgaHVnZXRsYl9ub19wYWdlKHN0cnVjdCBtbV9zdHJ1Y3Qg
Km1tLCBzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKnZtYSwNCiAJCQkJJiYgKHZtYS0+dm1fZmxhZ3Mg
JiBWTV9TSEFSRUQpKSk7DQogCXNldF9odWdlX3B0ZV9hdChtbSwgYWRkcmVzcywgcHRlcCwgbmV3
X3B0ZSk7DQogDQorCWluY19odWdldGxiX2NvdW50KG1tLCBoKTsNCiAJaWYgKChmbGFncyAmIEZB
VUxUX0ZMQUdfV1JJVEUpICYmICEodm1hLT52bV9mbGFncyAmIFZNX1NIQVJFRCkpIHsNCiAJCS8q
IE9wdGltaXphdGlvbiwgZG8gdGhlIENPVyB3aXRob3V0IGEgc2Vjb25kIGZhdWx0ICovDQogCQly
ZXQgPSBodWdldGxiX2NvdyhtbSwgdm1hLCBhZGRyZXNzLCBwdGVwLCBuZXdfcHRlLCBwYWdlLCBw
dGwpOw0KZGlmZiAtLWdpdCB2NC4yLXJjNC9tbS9tbWFwLmMgdjQuMi1yYzRfcGF0Y2hlZC9tbS9t
bWFwLmMNCmluZGV4IGFhNjMyYWRlMmJlNy4uOWQ5NTYyYmM3OWE4IDEwMDY0NA0KLS0tIHY0LjIt
cmM0L21tL21tYXAuYw0KKysrIHY0LjItcmM0X3BhdGNoZWQvbW0vbW1hcC5jDQpAQCAtMjg0Nyw2
ICsyODQ3LDcgQEAgdm9pZCBleGl0X21tYXAoc3RydWN0IG1tX3N0cnVjdCAqbW0pDQogCQkJbnJf
YWNjb3VudGVkICs9IHZtYV9wYWdlcyh2bWEpOw0KIAkJdm1hID0gcmVtb3ZlX3ZtYSh2bWEpOw0K
IAl9DQorCWV4aXRfaHVnZXRsYl9tbWFwKG1tKTsNCiAJdm1fdW5hY2N0X21lbW9yeShucl9hY2Nv
dW50ZWQpOw0KIH0NCiANCmRpZmYgLS1naXQgdjQuMi1yYzQvbW0vcm1hcC5jIHY0LjItcmM0X3Bh
dGNoZWQvbW0vcm1hcC5jDQppbmRleCAxNzFiNjg3NjhkZjEuLmIzMzI3OGJjNGRkYiAxMDA2NDQN
Ci0tLSB2NC4yLXJjNC9tbS9ybWFwLmMNCisrKyB2NC4yLXJjNF9wYXRjaGVkL21tL3JtYXAuYw0K
QEAgLTEyMzAsNyArMTIzMCw5IEBAIHN0YXRpYyBpbnQgdHJ5X3RvX3VubWFwX29uZShzdHJ1Y3Qg
cGFnZSAqcGFnZSwgc3RydWN0IHZtX2FyZWFfc3RydWN0ICp2bWEsDQogCXVwZGF0ZV9oaXdhdGVy
X3JzcyhtbSk7DQogDQogCWlmIChQYWdlSFdQb2lzb24ocGFnZSkgJiYgIShmbGFncyAmIFRUVV9J
R05PUkVfSFdQT0lTT04pKSB7DQotCQlpZiAoIVBhZ2VIdWdlKHBhZ2UpKSB7DQorCQlpZiAoUGFn
ZUh1Z2UocGFnZSkpIHsNCisJCQlkZWNfaHVnZXRsYl9jb3VudChtbSwgcGFnZV9oc3RhdGUocGFn
ZSkpOw0KKwkJfSBlbHNlIHsNCiAJCQlpZiAoUGFnZUFub24ocGFnZSkpDQogCQkJCWRlY19tbV9j
b3VudGVyKG1tLCBNTV9BTk9OUEFHRVMpOw0KIAkJCWVsc2UNCi0tIA0KMi40LjMNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1210418

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-20 13:10 +0200
Message-ID<pZvTk-337-21@gated-at.bofh.it>
In reply to#1210289
On Thu 20-08-15 08:26:27, Naoya Horiguchi wrote:
> Currently there's no easy way to get per-process usage of hugetlb pages,

Is this really the case after your previous patch? You have both 
HugetlbPages and KernelPageSize which should be sufficient no?

Reading a single file is, of course, easier but is it really worth the
additional code? I haven't really looked at the patch so I might be
missing something but what would be an advantage over reading
/proc/<pid>/smaps and extracting the information from there?

[...]
>  Documentation/filesystems/proc.txt |  3 +++
>  fs/hugetlbfs/inode.c               | 12 ++++++++++
>  fs/proc/task_mmu.c                 |  1 +
>  include/linux/hugetlb.h            | 36 +++++++++++++++++++++++++++++
>  include/linux/mm_types.h           |  7 ++++++
>  kernel/fork.c                      |  3 +++
>  mm/hugetlb.c                       | 46 ++++++++++++++++++++++++++++++++++++++
>  mm/mmap.c                          |  1 +
>  mm/rmap.c                          |  4 +++-
>  9 files changed, 112 insertions(+), 1 deletion(-)
[...]
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210709

FromDavid Rientjes <rientjes@google.com>
Date2015-08-20 22:00 +0200
Message-ID<pZEae-6lY-13@gated-at.bofh.it>
In reply to#1210418
On Thu, 20 Aug 2015, Michal Hocko wrote:

> On Thu 20-08-15 08:26:27, Naoya Horiguchi wrote:
> > Currently there's no easy way to get per-process usage of hugetlb pages,
> 
> Is this really the case after your previous patch? You have both 
> HugetlbPages and KernelPageSize which should be sufficient no?
> 
> Reading a single file is, of course, easier but is it really worth the
> additional code? I haven't really looked at the patch so I might be
> missing something but what would be an advantage over reading
> /proc/<pid>/smaps and extracting the information from there?
> 

/proc/pid/smaps requires root, /proc/pid/status doesn't.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210931

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-21 08:40 +0200
Message-ID<pZO9B-44i-33@gated-at.bofh.it>
In reply to#1210709
On Thu 20-08-15 12:49:59, David Rientjes wrote:
> On Thu, 20 Aug 2015, Michal Hocko wrote:
> 
> > On Thu 20-08-15 08:26:27, Naoya Horiguchi wrote:
> > > Currently there's no easy way to get per-process usage of hugetlb pages,
> > 
> > Is this really the case after your previous patch? You have both 
> > HugetlbPages and KernelPageSize which should be sufficient no?
> > 
> > Reading a single file is, of course, easier but is it really worth the
> > additional code? I haven't really looked at the patch so I might be
> > missing something but what would be an advantage over reading
> > /proc/<pid>/smaps and extracting the information from there?
> > 
> 
> /proc/pid/smaps requires root, /proc/pid/status doesn't.

Both mmotm and linus tree have
        REG("smaps",      S_IRUGO, proc_pid_smaps_operations),

and opening the file requires PTRACE_MODE_READ. So I do not see any
requirement for root here. Or did you mean that you need root to examine
all processes? That would be true but I am wondering why would be a regular
user interested in this break out numbers. Hugetlb management sounds
pretty much like an administrative or very specialized thing.

From my understanding of the discussion there is no usecase to have this
information world readable. Is this correct?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211252

FromJörn Engel <joern@purestorage.com>
Date2015-08-21 18:40 +0200
Message-ID<pZXwf-Hs-35@gated-at.bofh.it>
In reply to#1210931
On Fri, Aug 21, 2015 at 08:32:33AM +0200, Michal Hocko wrote:
> 
> Both mmotm and linus tree have
>         REG("smaps",      S_IRUGO, proc_pid_smaps_operations),
> 
> and opening the file requires PTRACE_MODE_READ. So I do not see any
> requirement for root here. Or did you mean that you need root to examine
> all processes? That would be true but I am wondering why would be a regular
> user interested in this break out numbers. Hugetlb management sounds
> pretty much like an administrative or very specialized thing.
> 
> From my understanding of the discussion there is no usecase to have this
> information world readable. Is this correct?

Well, tools like top currently display rss.  Once we have some
interface, I would like a version of top that displays the true rss
including hugepages (hrss maybe?).

If we make such a tool impossible today, someone will complain about it
in the future and we created a new mess for ourselves.  I think it is
trouble enough to deal with the old one.

Jörn

--
Denying any reality for any laudable political goal is a bad strategy.
When the facts come out, the discovery of the facts will undermine the
laudable political goals.
-- Jared Diamond
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210791

FromNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Date2015-08-21 01:40 +0200
Message-ID<pZHB8-33E-15@gated-at.bofh.it>
In reply to#1210418
T24gVGh1LCBBdWcgMjAsIDIwMTUgYXQgMDE6MDA6MDVQTSArMDIwMCwgTWljaGFsIEhvY2tvIHdy
b3RlOg0KPiBPbiBUaHUgMjAtMDgtMTUgMDg6MjY6MjcsIE5hb3lhIEhvcmlndWNoaSB3cm90ZToN
Cj4gPiBDdXJyZW50bHkgdGhlcmUncyBubyBlYXN5IHdheSB0byBnZXQgcGVyLXByb2Nlc3MgdXNh
Z2Ugb2YgaHVnZXRsYiBwYWdlcywNCj4gDQo+IElzIHRoaXMgcmVhbGx5IHRoZSBjYXNlIGFmdGVy
IHlvdXIgcHJldmlvdXMgcGF0Y2g/IFlvdSBoYXZlIGJvdGggDQo+IEh1Z2V0bGJQYWdlcyBhbmQg
S2VybmVsUGFnZVNpemUgd2hpY2ggc2hvdWxkIGJlIHN1ZmZpY2llbnQgbm8/DQoNCldlIGNhbiBj
YWxjdXJhdGUgaXQgZnJvbSB0aGVzZSBpbmZvLCBzbyBzYXlpbmcgIm5vIGVhc3kgd2F5IiB3YXMg
aW5jb3JyZWN0IDooDQoNCj4gUmVhZGluZyBhIHNpbmdsZSBmaWxlIGlzLCBvZiBjb3Vyc2UsIGVh
c2llciBidXQgaXMgaXQgcmVhbGx5IHdvcnRoIHRoZQ0KPiBhZGRpdGlvbmFsIGNvZGU/IEkgaGF2
ZW4ndCByZWFsbHkgbG9va2VkIGF0IHRoZSBwYXRjaCBzbyBJIG1pZ2h0IGJlDQo+IG1pc3Npbmcg
c29tZXRoaW5nIGJ1dCB3aGF0IHdvdWxkIGJlIGFuIGFkdmFudGFnZSBvdmVyIHJlYWRpbmcNCj4g
L3Byb2MvPHBpZD4vc21hcHMgYW5kIGV4dHJhY3RpbmcgdGhlIGluZm9ybWF0aW9uIGZyb20gdGhl
cmU/DQoNCk15IGZpcnN0IGlkZWEgd2FzIGp1c3QgInVzZXJzIHNob3VsZCBmZWVsIGl0IHVzZWZ1
bCIsIGJ1dCBwZXJtaXNzaW9uIGFzIERhdmlkDQpjb21tZW50ZWQgc291bmRzIGEgZ29vZCB0ZWNo
bmljYWwgcmVhc29uIHRvIG1lLg0KDQpUaGFua3MsDQpOYW95YSBIb3JpZ3VjaGk=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1210946

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-21 09:00 +0200
Message-ID<pZOsW-4qZ-1@gated-at.bofh.it>
In reply to#1210791
On Thu 20-08-15 23:34:51, Naoya Horiguchi wrote:
[...]
> > Reading a single file is, of course, easier but is it really worth the
> > additional code? I haven't really looked at the patch so I might be
> > missing something but what would be an advantage over reading
> > /proc/<pid>/smaps and extracting the information from there?
> 
> My first idea was just "users should feel it useful", but permission as David
> commented sounds a good technical reason to me.

9 files changed, 112 insertions(+), 1 deletion(-)

is quite a lot especially when it touches hot paths like fork so it
better should have a good usecase. I have already asked in the other
email but is actually anybody requesting this? Nice to have is not
a good justification IMO.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211250

FromJörn Engel <joern@purestorage.com>
Date2015-08-21 18:40 +0200
Message-ID<pZXwe-Hs-19@gated-at.bofh.it>
In reply to#1210946
On Fri, Aug 21, 2015 at 08:53:21AM +0200, Michal Hocko wrote:
> On Thu 20-08-15 23:34:51, Naoya Horiguchi wrote:
> [...]
> > > Reading a single file is, of course, easier but is it really worth the
> > > additional code? I haven't really looked at the patch so I might be
> > > missing something but what would be an advantage over reading
> > > /proc/<pid>/smaps and extracting the information from there?
> > 
> > My first idea was just "users should feel it useful", but permission as David
> > commented sounds a good technical reason to me.
> 
> 9 files changed, 112 insertions(+), 1 deletion(-)
> 
> is quite a lot especially when it touches hot paths like fork so it
> better should have a good usecase. I have already asked in the other
> email but is actually anybody requesting this? Nice to have is not
> a good justification IMO.

I need some way to judge the real rss of a process, including huge
pages.  No strong opinion on implementation details, but something is
clearly needed.

If you have processes with 99% huge pages, you are currently reduced to
guesswork.

Jörn

--
Journalism is printing what someone else does not want printed;
everything else is public relations.
-- George Orwell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1211927

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-24 11:00 +0200
Message-ID<q0VLI-2M2-3@gated-at.bofh.it>
In reply to#1211250
On Fri 21-08-15 09:30:33, Jörn Engel wrote:
> On Fri, Aug 21, 2015 at 08:53:21AM +0200, Michal Hocko wrote:
> > On Thu 20-08-15 23:34:51, Naoya Horiguchi wrote:
> > [...]
> > > > Reading a single file is, of course, easier but is it really worth the
> > > > additional code? I haven't really looked at the patch so I might be
> > > > missing something but what would be an advantage over reading
> > > > /proc/<pid>/smaps and extracting the information from there?
> > > 
> > > My first idea was just "users should feel it useful", but permission as David
> > > commented sounds a good technical reason to me.
> > 
> > 9 files changed, 112 insertions(+), 1 deletion(-)
> > 
> > is quite a lot especially when it touches hot paths like fork so it
> > better should have a good usecase. I have already asked in the other
> > email but is actually anybody requesting this? Nice to have is not
> > a good justification IMO.
> 
> I need some way to judge the real rss of a process, including huge
> pages.  No strong opinion on implementation details, but something is
> clearly needed.

The current implementation makes me worry. Is the per hstate break down
really needed? The implementation would be much more easier without it.

> If you have processes with 99% huge pages, you are currently reduced to
> guesswork.

If you have 99% of hugetlb pages then your load is rather specific and I
would argue that /proc/<pid>/smaps (after patch 1) is a much better way to
get what you want.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213433

FromDavid Rientjes <rientjes@google.com>
Date2015-08-26 01:30 +0200
Message-ID<q1vPc-4OX-17@gated-at.bofh.it>
In reply to#1211927
On Mon, 24 Aug 2015, Michal Hocko wrote:

> The current implementation makes me worry. Is the per hstate break down
> really needed? The implementation would be much more easier without it.
> 

Yes, it's needed.  It provides a complete picture of what statically 
reserved hugepages are in use and we're not going to change the 
implementation when it is needed to differentiate between variable hugetlb 
page sizes that risk breaking existing userspace parsers.

> If you have 99% of hugetlb pages then your load is rather specific and I
> would argue that /proc/<pid>/smaps (after patch 1) is a much better way to
> get what you want.
> 

Some distributions change the permissions of smaps, as already stated, for 
pretty clear security reasons since it can be used to defeat existing 
protection.  There's no reason why hugetlb page usage should not be 
exported in the same manner and location as memory usage.

Sheesh.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1213581

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-26 08:40 +0200
Message-ID<q1Cxk-6ew-1@gated-at.bofh.it>
In reply to#1213433
On Tue 25-08-15 16:23:34, David Rientjes wrote:
> On Mon, 24 Aug 2015, Michal Hocko wrote:
> 
> > The current implementation makes me worry. Is the per hstate break down
> > really needed? The implementation would be much more easier without it.
> > 
> 
> Yes, it's needed.  It provides a complete picture of what statically 
> reserved hugepages are in use and we're not going to change the 
> implementation when it is needed to differentiate between variable hugetlb 
> page sizes that risk breaking existing userspace parsers.

I thought the purpose was to give the amount of hugetlb based
resident memory. At least this is what Jörn was asking for AFAIU.
/proc/<pid>/status should be as lightweight as possible. The current
implementation is quite heavy as already pointed out. So I am really
curious whether this is _really_ needed. I haven't heard about a real
usecase except for top displaying HRss which doesn't need the break
down values. You have brought that up already
http://marc.info/?l=linux-mm&m=143941143109335&w=2 and nobody actually
asked for it. "I do not mind having it" is not an argument for inclusion
especially when the implementation is more costly and touches hot paths.

> > If you have 99% of hugetlb pages then your load is rather specific and I
> > would argue that /proc/<pid>/smaps (after patch 1) is a much better way to
> > get what you want.
> 
> Some distributions change the permissions of smaps, as already stated, for 
> pretty clear security reasons since it can be used to defeat existing 
> protection.  There's no reason why hugetlb page usage should not be 
> exported in the same manner and location as memory usage.

/proc/<pid>/status provides only per-memory-type break down information
(locked, data, stack, etc...). Different hugetlb sizes are still a
hugetlb memory. So I am not sure I understand you argument here.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1214218

FromDavid Rientjes <rientjes@google.com>
Date2015-08-27 00:10 +0200
Message-ID<q1R3j-1Qg-13@gated-at.bofh.it>
In reply to#1213581

[Multipart message — attachments visible in raw view] — view raw

On Wed, 26 Aug 2015, Michal Hocko wrote:

> I thought the purpose was to give the amount of hugetlb based
> resident memory.

Persistent hugetlb memory is always resident, the goal is to show what is 
currently mapped.

> At least this is what Jörn was asking for AFAIU.
> /proc/<pid>/status should be as lightweight as possible. The current
> implementation is quite heavy as already pointed out. So I am really
> curious whether this is _really_ needed. I haven't heard about a real
> usecase except for top displaying HRss which doesn't need the break
> down values. You have brought that up already
> http://marc.info/?l=linux-mm&m=143941143109335&w=2 and nobody actually
> asked for it. "I do not mind having it" is not an argument for inclusion
> especially when the implementation is more costly and touches hot paths.
> 

It iterates over HUGE_MAX_HSTATE and reads atomic usage counters twice.  
On x86, HUGE_MAX_HSTATE == 2.  I don't consider that to be expensive.

If you are concerned about the memory allocation of struct hugetlb_usage, 
it could easily be embedded directly in struct mm_struct.

[toc] | [prev] | [next] | [standalone]

#1214347

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-27 08:50 +0200
Message-ID<q1Zay-524-19@gated-at.bofh.it>
In reply to#1214218
On Wed 26-08-15 15:02:49, David Rientjes wrote:
> On Wed, 26 Aug 2015, Michal Hocko wrote:
> 
> > I thought the purpose was to give the amount of hugetlb based
> > resident memory.
> 
> Persistent hugetlb memory is always resident, the goal is to show what is 
> currently mapped.
> 
> > At least this is what Jörn was asking for AFAIU.
> > /proc/<pid>/status should be as lightweight as possible. The current
> > implementation is quite heavy as already pointed out. So I am really
> > curious whether this is _really_ needed. I haven't heard about a real
> > usecase except for top displaying HRss which doesn't need the break
> > down values. You have brought that up already
> > http://marc.info/?l=linux-mm&m=143941143109335&w=2 and nobody actually
> > asked for it. "I do not mind having it" is not an argument for inclusion
> > especially when the implementation is more costly and touches hot paths.
> > 
> 
> It iterates over HUGE_MAX_HSTATE and reads atomic usage counters twice.  

I am not worried about /proc/<pid>/status read path. That one is indeed
trivial.

> On x86, HUGE_MAX_HSTATE == 2.  I don't consider that to be expensive.
> 
> If you are concerned about the memory allocation of struct hugetlb_usage, 
> it could easily be embedded directly in struct mm_struct.

Yes I am concerned about that and
9 files changed, 112 insertions(+), 1 deletion(-)
for something that is even not clear to be really required. And I still
haven't heard any strong usecase to justify it.

Can we go with the single and much simpler cumulative number first and
only add the break down list if it is _really_ required? We can even
document that the future version of /proc/<pid>/status might add an
additional information to prepare all the parsers to be more careful.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1214735

FromJörn Engel <joern@purestorage.com>
Date2015-08-27 19:30 +0200
Message-ID<q299V-2Go-23@gated-at.bofh.it>
In reply to#1214347
On Thu, Aug 27, 2015 at 08:48:18AM +0200, Michal Hocko wrote:
> 
> > On x86, HUGE_MAX_HSTATE == 2.  I don't consider that to be expensive.
> > 
> > If you are concerned about the memory allocation of struct hugetlb_usage, 
> > it could easily be embedded directly in struct mm_struct.
> 
> Yes I am concerned about that and
> 9 files changed, 112 insertions(+), 1 deletion(-)
> for something that is even not clear to be really required. And I still
> haven't heard any strong usecase to justify it.
> 
> Can we go with the single and much simpler cumulative number first and
> only add the break down list if it is _really_ required? We can even
> document that the future version of /proc/<pid>/status might add an
> additional information to prepare all the parsers to be more careful.

I don't care much which way we decide.  But I find your reasoning a bit
worrying.  If someone asks for a by-size breakup of hugepages in a few
years, you might have existing binaries that depend on the _absence_ of
those extra characters on the line.

Compare:
  HugetlbPages:      18432 kB
  HugetlbPages:    1069056 kB (1*1048576kB 10*2048kB)

Once someone has written a script that greps for 'HugetlbPages:.*kB$',
you have lost the option of adding anything else to the line.  You have
created yet another ABI compatibility headache today in order to save
112 lines of code.

That may be a worthwhile tradeoff, I don't know.  But at least I realize
there is a cost, while you seem to ignore that component.  There is
value in not painting yourself into a corner.

Jörn

--
A quarrel is quickly settled when deserted by one party; there is
no battle unless there be two.
-- Seneca
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1214821

FromDavid Rientjes <rientjes@google.com>
Date2015-08-27 22:50 +0200
Message-ID<q2cht-74J-11@gated-at.bofh.it>
In reply to#1214735

[Multipart message — attachments visible in raw view] — view raw

On Thu, 27 Aug 2015, Jörn Engel wrote:

> On Thu, Aug 27, 2015 at 08:48:18AM +0200, Michal Hocko wrote:
> > Can we go with the single and much simpler cumulative number first and
> > only add the break down list if it is _really_ required? We can even
> > document that the future version of /proc/<pid>/status might add an
> > additional information to prepare all the parsers to be more careful.
> 
> I don't care much which way we decide.  But I find your reasoning a bit
> worrying.  If someone asks for a by-size breakup of hugepages in a few
> years, you might have existing binaries that depend on the _absence_ of
> those extra characters on the line.
> 
> Compare:
>   HugetlbPages:      18432 kB
>   HugetlbPages:    1069056 kB (1*1048576kB 10*2048kB)
> 
> Once someone has written a script that greps for 'HugetlbPages:.*kB$',
> you have lost the option of adding anything else to the line.  You have
> created yet another ABI compatibility headache today in order to save
> 112 lines of code.
> 

This is exactly the concern that I have brought up in this thread.  We 
have no other way to sanely export the breakdown in hugepage size without 
new fields being added later with the hstate size being embedded in the 
name itself.

I agree with the code as it stands in -mm today and I'm thankful to Naoya 
that a long-term maintainable API has been established.  Respectfully, I 
have no idea why we are still talking about this and I'm not going to be 
responding further unless something changes in -mm.

[toc] | [prev] | [next] | [standalone]

#1216119

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-31 11:20 +0200
Message-ID<q3tpT-3oo-1@gated-at.bofh.it>
In reply to#1214735
On Thu 27-08-15 10:23:51, Jörn Engel wrote:
> On Thu, Aug 27, 2015 at 08:48:18AM +0200, Michal Hocko wrote:
> > 
> > > On x86, HUGE_MAX_HSTATE == 2.  I don't consider that to be expensive.
> > > 
> > > If you are concerned about the memory allocation of struct hugetlb_usage, 
> > > it could easily be embedded directly in struct mm_struct.
> > 
> > Yes I am concerned about that and
> > 9 files changed, 112 insertions(+), 1 deletion(-)
> > for something that is even not clear to be really required. And I still
> > haven't heard any strong usecase to justify it.
> > 
> > Can we go with the single and much simpler cumulative number first and
> > only add the break down list if it is _really_ required? We can even
> > document that the future version of /proc/<pid>/status might add an
> > additional information to prepare all the parsers to be more careful.
> 
> I don't care much which way we decide.  But I find your reasoning a bit
> worrying.  If someone asks for a by-size breakup of hugepages in a few
> years, you might have existing binaries that depend on the _absence_ of
> those extra characters on the line.
> 
> Compare:
>   HugetlbPages:      18432 kB
>   HugetlbPages:    1069056 kB (1*1048576kB 10*2048kB)
> 
> Once someone has written a script that greps for 'HugetlbPages:.*kB$',
> you have lost the option of adding anything else to the line. 

If you think that an explicit note in the documentation is
not sufficient then I believe we can still handle it backward
compatible. Like separate entries for each existing hugetlb page:
HugetlbPages:	     1069056 kB
Hugetlb2MPages:	     20480 kB
Hugetlb1GPages:	     1048576 kB

or something similar. I would even argue this would be slightly easier
to parse. So it is not like we would be locked into anything.

> You have
> created yet another ABI compatibility headache today in order to save
> 112 lines of code.
> 
> That may be a worthwhile tradeoff, I don't know.  But at least I realize
> there is a cost, while you seem to ignore that component.  There is
> value in not painting yourself into a corner.

My primary point was that we are adding a code for a feature nobody
actually asked for just because somebody might ask for it in future.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web