[patch] bootmem-2.3.25-A0

Ingo Molnar (mingo@chiara.csoma.elte.hu)
Wed, 3 Nov 1999 13:09:40 +0100 (CET)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

--650352740-778846371-941616010=:1171
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9911030900331.1171@chiara.csoma.elte.hu>

On Tue, 2 Nov 1999, Russell King wrote:

> > > This is just Ingo being bad. He should have used virt_to_phys() and
> > > friends, not __pa().
>
> IMHO, __pa should not be the same as virt_to_phys(). [...]

i've fixed this already in my tree (patch attached) - but i do not think
this should make any difference. bootmem.c does not deal with vmalloced or
ioremapped memory, so __pa/__va should be identical to virt_to_phys /
phys_to_virt.

The patch also adds a simple (and fast) intrusive RAM tester [saw the idea
of boot-time RAM testing in Pavel Machek's patch], this can be done in
bootmem.c in a very straightforward way. Pages are tested right before
they are freed. Only pages that are explicitly marked as usable are
tested, ie. boot-parameter-forced memory maps can be used to ignore faulty
RAM. This feature should also help us sorting out memory detection
inconsistencies. [bootmem.c still has some debugging checks, this will be
removed later.]

> However, as Roman points out, if the bootmem stuff is to use
> virt_to_phys(), unless a "start" page number is passed in, the bit
> array could be unnecessarily large, and may in certain systems cause
> major problems (systems with many small (512KB) banks of memory).

there is a single place where bootmem.c uses virt_to_phys, and thats a
constant address (MAX_DMA_ADDRESS). I'd be surprised if there was any
difference between virt_to_phys() and __pa() in this case. There were
several uses of __va() in bootmem.c - can there be any theoretical
difference between __va() and phys_to_virt()?

Niibe Yutaka (the SH maintainer) noticed this 'too big bitmap and memory
map' problem too, and he promised to send patches for this in a few days.
(it's a bit hard to test this on x86) It's not really a problem with the
bootmem.c bitmap (that one is getting freed after bootup anyway), the real
problem is mem_map[], which can get unnecesserily big if there are too
many 'holes' in the physical memory layout.

-- mingo

--650352740-778846371-941616010=:1171
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="bootmem-2.3.25-A0"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9911030900100.1171@chiara.csoma.elte.hu>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="bootmem-2.3.25-A0"

LS0tIGxpbnV4L21tL2Jvb3RtZW0uYy5vcmlnCVR1ZSBOb3YgIDIgMDQ6MjU6
MTEgMTk5OQ0KKysrIGxpbnV4L21tL2Jvb3RtZW0uYwlUdWUgTm92ICAyIDA4
OjEzOjM3IDE5OTkNCkBAIC0xNiw2ICsxNiw3IEBADQogI2luY2x1ZGUgPGxp
bnV4L2ludGVycnVwdC5oPg0KICNpbmNsdWRlIDxsaW51eC9pbml0Lmg+DQog
I2luY2x1ZGUgPGxpbnV4L2Jvb3RtZW0uaD4NCisjaW5jbHVkZSA8bGludXgv
aGlnaG1lbS5oPg0KICNpbmNsdWRlIDxhc20vZG1hLmg+DQogDQogLyoNCkBA
IC0zNiw5ICszNyw3IEBADQogew0KIAl1bnNpZ25lZCBsb25nIG1hcHNpemUg
PSAocGFnZXMrNykvODsNCiANCi0JaWYgKGJvb3RtZW1fbWFwKQ0KLQkJQlVH
KCk7DQotCWJvb3RtZW1fbWFwID0gX192YShzdGFydCA8PCBQQUdFX1NISUZU
KTsNCisJYm9vdG1lbV9tYXAgPSBwaHlzX3RvX3ZpcnQoc3RhcnQgPDwgUEFH
RV9TSElGVCk7DQogCW1heF9sb3dfcGZuID0gcGFnZXM7DQogDQogCS8qDQpA
QCAtNjQsNyArNjMsNiBAQA0KIAkgKi8NCiAJdW5zaWduZWQgbG9uZyBlbmQg
PSAoYWRkciArIHNpemUgKyBQQUdFX1NJWkUtMSkvUEFHRV9TSVpFOw0KIA0K
LQlpZiAoIWJvb3RtZW1fbWFwKSBCVUcoKTsNCiAJaWYgKCFzaXplKSBCVUco
KTsNCiANCiAJaWYgKGVuZCA+IG1heF9sb3dfcGZuKQ0KQEAgLTgzLDcgKzgx
LDYgQEANCiAJICovDQogCXVuc2lnbmVkIGxvbmcgZW5kID0gKGFkZHIgKyBz
aXplKS9QQUdFX1NJWkU7DQogDQotCWlmICghYm9vdG1lbV9tYXApIEJVRygp
Ow0KIAlpZiAoIXNpemUpIEJVRygpOw0KIA0KIAlpZiAoZW5kID4gbWF4X2xv
d19wZm4pDQpAQCAtMTE3LDcgKzExNCw2IEBADQogCXVuc2lnbmVkIGxvbmcg
b2Zmc2V0LCByZW1haW5pbmdfc2l6ZTsNCiAJdW5zaWduZWQgbG9uZyBhcmVh
c2l6ZSwgcHJlZmVycmVkOw0KIA0KLQlpZiAoIWJvb3RtZW1fbWFwKSBCVUco
KTsNCiAJaWYgKCFzaXplKSBCVUcoKTsNCiANCiAJLyoNCkBAIC0xNTIsNiAr
MTQ4LDkgQEANCiAJCXByZWZlcnJlZCA9IDA7DQogCQlnb3RvIHJlc3RhcnRf
c2NhbjsNCiAJfQ0KKwkvKg0KKwkgKiBXaG9vcHMsIHdlIGNhbm5vdCBzYXRp
c2Z5IHRoZSBhbGxvY2F0aW9uIHJlcXVlc3QuDQorCSAqLw0KIAlCVUcoKTsN
CiBmb3VuZDoNCiAJaWYgKHN0YXJ0ID49IG1heF9sb3dfcGZuKQ0KQEAgLTE3
MywxMSArMTcyLDExIEBADQogCQkJYXJlYXNpemUgPSAwOw0KIAkJCS8vIGxh
c3RfcG9zIHVuY2hhbmdlZA0KIAkJCWxhc3Rfb2Zmc2V0ID0gb2Zmc2V0K3Np
emU7DQotCQkJcmV0ID0gX192YShsYXN0X3BvcypQQUdFX1NJWkUgKyBvZmZz
ZXQpOw0KKwkJCXJldCA9IHBoeXNfdG9fdmlydChsYXN0X3BvcypQQUdFX1NJ
WkUgKyBvZmZzZXQpOw0KIAkJfSBlbHNlIHsNCiAJCQlzaXplIC09IHJlbWFp
bmluZ19zaXplOw0KIAkJCWFyZWFzaXplID0gKHNpemUrUEFHRV9TSVpFLTEp
L1BBR0VfU0laRTsNCi0JCQlyZXQgPSBfX3ZhKGxhc3RfcG9zKlBBR0VfU0la
RSArIG9mZnNldCk7DQorCQkJcmV0ID0gcGh5c190b192aXJ0KGxhc3RfcG9z
KlBBR0VfU0laRSArIG9mZnNldCk7DQogCQkJbGFzdF9wb3MgPSBzdGFydCth
cmVhc2l6ZS0xOw0KIAkJCWxhc3Rfb2Zmc2V0ID0gc2l6ZTsNCiAJCX0NCkBA
IC0xODUsNyArMTg0LDcgQEANCiAJfSBlbHNlIHsNCiAJCWxhc3RfcG9zID0g
c3RhcnQgKyBhcmVhc2l6ZSAtIDE7DQogCQlsYXN0X29mZnNldCA9IHNpemUg
JiB+UEFHRV9NQVNLOw0KLQkJcmV0ID0gX192YShzdGFydCAqIFBBR0VfU0la
RSk7DQorCQlyZXQgPSBwaHlzX3RvX3ZpcnQoc3RhcnQgKiBQQUdFX1NJWkUp
Ow0KIAl9DQogCS8qDQogCSAqIFJlc2VydmUgdGhlIGFyZWEgbm93Og0KQEAg
LTE5Nyw2ICsxOTYsNDEgQEANCiAJcmV0dXJuIHJldDsNCiB9DQogDQorLyoN
CisgKiBPbmx5IHRlc3QgZXZlcnkgVEVTVF9JTlRFUlZBTCBieXRlLCBtYWlu
IG1lbW9yeSBiYW5kd2l0aA0KKyAqIHNsb3dzIHRoaW5ncyBkb3duDQorICov
DQorI2RlZmluZSBURVNUX0lOVEVSVkFMIDY5DQorDQorc3RhdGljIHZvaWQg
c2lsbHlfdGVzdF9wYWdlKHN0cnVjdCBwYWdlICpwYWdlKQ0KK3sNCisJdm9s
YXRpbGUgdW5zaWduZWQgY2hhciAqIGthZGRyOw0KKwlpbnQgaTsNCisNCisJ
a2FkZHIgPSAoY2hhciAqKWttYXAocGFnZSwgS01fUkVBRCk7DQorDQorCS8q
DQorCSAqIFNpbXBsZSB0ZXN0IHRvIHNlZSB3ZXRoZXIgYWxsIGJpdHMgYXJl
IGludGFjdC4NCisJICovDQorCWZvciAoaSA9IDA7IGkgPCBQQUdFX1NJWkU7
IGkgKz0gVEVTVF9JTlRFUlZBTCkgew0KKwkJa2FkZHJbaV0gfD0gMHg1NTsN
CisJCWlmICgoa2FkZHJbaV0gJiAweDU1KSAhPSAweDU1KQ0KKwkJCWdvdG8g
ZmFpbHVyZTsNCisJCWthZGRyW2ldIHw9IDB4QUE7DQorCQlpZiAoa2FkZHJb
aV0gIT0gMHhmZikNCisJCQlnb3RvIGZhaWx1cmU7DQorCQlrYWRkcltpXSsr
Ow0KKwkJaWYgKGthZGRyW2ldICE9IDB4MDApDQorCQkJZ290byBmYWlsdXJl
Ow0KKwl9DQorDQorCWt1bm1hcCgodW5zaWduZWQgbG9uZylrYWRkciwgS01f
UkVBRCk7DQorCXJldHVybjsNCisNCitmYWlsdXJlOg0KKwlwYW5pYygibWVt
b3J5IHRlc3QgZmFpbGVkISIpOw0KK30NCisNCiB1bnNpZ25lZCBsb25nIF9f
aW5pdCBmcmVlX2FsbF9ib290bWVtICh2b2lkKQ0KIHsNCiAJc3RydWN0IHBh
Z2UgKiBwYWdlOw0KQEAgLTIwNCw2ICsyMzgsNyBAQA0KIA0KIAlpZiAoIWJv
b3RtZW1fbWFwKSBCVUcoKTsNCiANCisJcHJpbnRrKCJzaW1wbGUgUkFNLXRl
c3QgLi4uIik7DQogCXBhZ2UgPSBtZW1fbWFwOw0KIAljb3VudCA9IDA7DQog
CWZvciAoaSA9IDA7IGkgPCBtYXhfbG93X3BmbjsgaSsrLCBwYWdlKyspIHsN
CkBAIC0yMTEsOCArMjQ2LDkgQEANCiAJCQljb3VudCsrOw0KIAkJCUNsZWFy
UGFnZVJlc2VydmVkKHBhZ2UpOw0KIAkJCXNldF9wYWdlX2NvdW50KHBhZ2Us
IDEpOw0KLQkJCWlmIChpID49IChfX3BhKE1BWF9ETUFfQUREUkVTUykgPj4g
UEFHRV9TSElGVCkpDQorCQkJaWYgKGkgPj0gKHZpcnRfdG9fcGh5cygoY2hh
ciAqKU1BWF9ETUFfQUREUkVTUykgPj4gUEFHRV9TSElGVCkpDQogCQkJCWNs
ZWFyX2JpdChQR19ETUEsICZwYWdlLT5mbGFncyk7DQorCQkJc2lsbHlfdGVz
dF9wYWdlKHBhZ2UpOw0KIAkJCV9fZnJlZV9wYWdlKHBhZ2UpOw0KIAkJfQ0K
IAl9DQpAQCAtMjI3LDEwICsyNjMsMTMgQEANCiAJCWNvdW50Kys7DQogCQlD
bGVhclBhZ2VSZXNlcnZlZChwYWdlKTsNCiAJCXNldF9wYWdlX2NvdW50KHBh
Z2UsIDEpOw0KKwkJc2lsbHlfdGVzdF9wYWdlKHBhZ2UpOw0KIAkJX19mcmVl
X3BhZ2UocGFnZSk7DQogCX0NCiAJdG90YWwgKz0gY291bnQ7DQogCWJvb3Rt
ZW1fbWFwID0gTlVMTDsNCisNCisJcHJpbnRrKCIgcGFzc2VkLlxuIik7DQog
DQogCXJldHVybiB0b3RhbDsNCiB9DQo=
--650352740-778846371-941616010=:1171--

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