--168447515-98433695-1004460778=:8603
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 30 Oct 2001, Hugh Dickins wrote:
>
> However, unlike 2.4.13, 2.4.14-pre (you tried pre4, I just tried pre5)
> seems much too unwilling to shrink_dcache and shrink_icache: your
> memory hog should shrink them, but it seems not to. Linus?
Yes. It's next on my list.
My _preferred_ approach would actually be to move the slab pages to the
LRU list too, and have a special "slab" address space (we don't need to
actually hash them, we just make page->mapping point to it), and have the
cache shrink be done naturally as part of writepage().
That way "shrink_cache()" reacts very naturally to slab pressure, while
right now it's more of a random behaviour. That's what the "anonymous
pages in the LRU" approach fixes - the VM scanning reacts very naturally
(instead of with subtle tweaking and almost random behaviour) to mapped
page pressure.
The "slab address space" is a longer-range plan, though. It migth be
really simple (the writepage would just move the page to the active list
and try to shrink the slab that was hit), but I think the current stuff is
"good enough".
So in the short range, I haven't come up with any really good approaches,
but I suspect I'll just have to move the shrink_[di]cache() back to the
caller, which will at least shrink them on swapouts (a bit too much, I
think, but on the other hand maybe not).
Patch attached,
Linus
--168447515-98433695-1004460778=:8603
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=slab
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0110300852580.8603@penguin.transmeta.com>
Content-Description:
Content-Disposition: attachment; filename=slab
ZGlmZiAtdSAtLXJlY3Vyc2l2ZSBwcmU1L2xpbnV4L21tL3Ztc2Nhbi5jIGxp
bnV4L21tL3Ztc2Nhbi5jDQotLS0gcHJlNS9saW51eC9tbS92bXNjYW4uYwlU
dWUgT2N0IDMwIDA4OjUxOjEzIDIwMDENCisrKyBsaW51eC9tbS92bXNjYW4u
YwlUdWUgT2N0IDMwIDA4OjQ2OjA4IDIwMDENCkBAIC01MTUsMjAgKzUxNSw2
IEBADQogCX0NCiAJc3Bpbl91bmxvY2soJnBhZ2VtYXBfbHJ1X2xvY2spOw0K
IA0KLQlpZiAobnJfcGFnZXMgPD0gMCkNCi0JCXJldHVybiAwOw0KLQ0KLQkv
Kg0KLQkgKiBJZiBzd2FwcGluZyBvdXQgaXNuJ3QgYXBwcm9wcmlhdGUsIGFu
ZCANCi0JICogd2Ugc3RpbGwgZmFpbCwgdHJ5IHRoZSBvdGhlciAodXN1YWxs
eSBzbWFsbGVyKQ0KLQkgKiBjYWNoZXMgaW5zdGVhZC4NCi0JICovDQotCXNo
cmlua19kY2FjaGVfbWVtb3J5KHByaW9yaXR5LCBnZnBfbWFzayk7DQotCXNo
cmlua19pY2FjaGVfbWVtb3J5KHByaW9yaXR5LCBnZnBfbWFzayk7DQotI2lm
ZGVmIENPTkZJR19RVU9UQQ0KLQlzaHJpbmtfZHFjYWNoZV9tZW1vcnkoREVG
X1BSSU9SSVRZLCBnZnBfbWFzayk7DQotI2VuZGlmDQotDQogCXJldHVybiBu
cl9wYWdlczsNCiB9DQogDQpAQCAtNTc3LDcgKzU2MywxNyBAQA0KIAlyYXRp
byA9ICh1bnNpZ25lZCBsb25nKSBucl9wYWdlcyAqIG5yX2FjdGl2ZV9wYWdl
cyAvICgobnJfaW5hY3RpdmVfcGFnZXMgKyAxKSAqIDIpOw0KIAlyZWZpbGxf
aW5hY3RpdmUocmF0aW8pOw0KIA0KLQlyZXR1cm4gc2hyaW5rX2NhY2hlKG5y
X3BhZ2VzLCBjbGFzc3pvbmUsIGdmcF9tYXNrLCBwcmlvcml0eSk7DQorCW5y
X3BhZ2VzID0gc2hyaW5rX2NhY2hlKG5yX3BhZ2VzLCBjbGFzc3pvbmUsIGdm
cF9tYXNrLCBwcmlvcml0eSk7DQorCWlmIChucl9wYWdlcyA8PSAwKQ0KKwkJ
cmV0dXJuIDA7DQorDQorCXNocmlua19kY2FjaGVfbWVtb3J5KHByaW9yaXR5
LCBnZnBfbWFzayk7DQorCXNocmlua19pY2FjaGVfbWVtb3J5KHByaW9yaXR5
LCBnZnBfbWFzayk7DQorI2lmZGVmIENPTkZJR19RVU9UQQ0KKwlzaHJpbmtf
ZHFjYWNoZV9tZW1vcnkoREVGX1BSSU9SSVRZLCBnZnBfbWFzayk7DQorI2Vu
ZGlmDQorDQorCXJldHVybiBucl9wYWdlczsNCiB9DQogDQogaW50IHRyeV90
b19mcmVlX3BhZ2VzKHpvbmVfdCAqY2xhc3N6b25lLCB1bnNpZ25lZCBpbnQg
Z2ZwX21hc2ssIHVuc2lnbmVkIGludCBvcmRlcikNCg0K
--168447515-98433695-1004460778=:8603--
-
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/