[patch-2.4.0-test6-pre6] fs_cachep (was Re: [PATCH] signal_struct

[Tigran Aivazian]

  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 [e-mail] for more info.

---1463811838-1964021912-965660704=:878
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Mark and Linus,

Although Mark's comments are definitely correct (AFAICS) - I remembered
that the classical SLAB paper mentioned one of the advantages of
converting things to using slab allocator in order to serve as some sort
of system administration tool - i.e. to see which subsystems are putting
lots of pressure on VM and which aren't. If they all use generic
kmalloc/kfree this information/stats is not visible.

So I converted p->fs allocation to a SLAB cache of its own - see the patch
attached - tested under 2.4.0-test6-pre6.

A copy of the patch is on:

http://www.moses.uklinux.net/patches/fscache-2.4.0-test6-pre6.patch

Regards,
Tigran

On Mon, 7 Aug 2000, Mark Hemment wrote:

> Tigran,
> 
> > What about small (36 byte) things like fs_struct - looks like it is the
> > only one left as kmalloc'd still - is there any point to convert it to a
> > cache of its own - fs_cachep?
> > 
> > I understand it will come from 64 byte generic cache so perhaps it is just
> > as wasteful? Or do you (SLAB) store some useful ctl info in those
> > remaining bytes?
> 
>   Probably not worth it for fs_cachep.  But should be need investigated.
> 
>   My old slab allocator would fit a control struct behind the actual
> object (in between the padding to an L1 bound).  With Manfred's changes, I
> believe this to still be the case.
> 
>   The new allocator I'm working on will also fit the control struct
> between objects (and at the end of a slab, and off-slab).  Plus, it will
> allow different caches (with similar attributes) to share slabs - this is
> only useful on low memory machines for caches which tend to have very few
> allocations from them (say, the uid-cache, which takes up a full page for
> only a few allocations on some system usage patterns - it would be
> better off using one of the general sized caches - which is why I
> originally implemented kmem_find_general_cachep()).
> 
> Mark
> 
> 

---1463811838-1964021912-965660704=:878
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="fscache-2.4.0-test6-pre6.patch"
Content-ID: <[e-mail]>
Content-Description: fs_cachep for p->fs allocation (2.4.0-test6-pre6)
Content-Disposition: attachment; filename="fscache-2.4.0-test6-pre6.patch"
Content-Transfer-Encoding: BASE64

ZGlmZiAtdXJOIC1YIGRvbnRkaWZmIGxpbnV4L2ZzL2RjYWNoZS5jIGZzY2Fj
aGUvZnMvZGNhY2hlLmMNCi0tLSBsaW51eC9mcy9kY2FjaGUuYwlNb24gQXVn
ICA3IDA4OjU3OjU3IDIwMDANCisrKyBmc2NhY2hlL2ZzL2RjYWNoZS5jCU1v
biBBdWcgIDcgMTU6NTA6NDAgMjAwMA0KQEAgLTEyNDAsNiArMTI0MCw5IEBA
DQogLyogU0xBQiBjYWNoZSBmb3IgYnVmZmVyX2hlYWQgc3RydWN0dXJlcyAq
Lw0KIGttZW1fY2FjaGVfdCAqYmhfY2FjaGVwOw0KIA0KKy8qIFNMQUIgY2Fj
aGUgZm9yIGZzX3N0cnVjdCBzdHJ1Y3R1cmVzICovDQora21lbV9jYWNoZV90
ICpmc19jYWNoZXA7DQorDQogdm9pZCBfX2luaXQgdmZzX2NhY2hlc19pbml0
KHVuc2lnbmVkIGxvbmcgbWVtcGFnZXMpDQogew0KIAliaF9jYWNoZXAgPSBr
bWVtX2NhY2hlX2NyZWF0ZSgiYnVmZmVyX2hlYWQiLA0KQEAgLTEyNTMsNiAr
MTI1NiwxMiBAQA0KIAkJCVNMQUJfSFdDQUNIRV9BTElHTiwgTlVMTCwgTlVM
TCk7DQogCWlmICghbmFtZXNfY2FjaGVwKQ0KIAkJcGFuaWMoIkNhbm5vdCBj
cmVhdGUgbmFtZXMgU0xBQiBjYWNoZSIpOw0KKw0KKwlmc19jYWNoZXAgPSBr
bWVtX2NhY2hlX2NyZWF0ZSgiZnNfY2FjaGUiLCANCisJCQkgc2l6ZW9mKHN0
cnVjdCBmc19zdHJ1Y3QpLCAwLCANCisJCQkgU0xBQl9IV0NBQ0hFX0FMSUdO
LCBOVUxMLCBOVUxMKTsNCisJaWYgKCFmc19jYWNoZXApIA0KKwkJcGFuaWMo
IkNhbm5vdCBjcmVhdGUgZnNfc3RydWN0IFNMQUIgY2FjaGUiKTsNCiANCiAJ
ZmlsZXNfY2FjaGVwID0ga21lbV9jYWNoZV9jcmVhdGUoImZpbGVzX2NhY2hl
IiwgDQogCQkJIHNpemVvZihzdHJ1Y3QgZmlsZXNfc3RydWN0KSwgMCwgDQpk
aWZmIC11ck4gLVggZG9udGRpZmYgbGludXgvaW5jbHVkZS9saW51eC9zbGFi
LmggZnNjYWNoZS9pbmNsdWRlL2xpbnV4L3NsYWIuaA0KLS0tIGxpbnV4L2lu
Y2x1ZGUvbGludXgvc2xhYi5oCU1vbiBBdWcgIDcgMDg6NTc6NTggMjAwMA0K
KysrIGZzY2FjaGUvaW5jbHVkZS9saW51eC9zbGFiLmgJTW9uIEF1ZyAgNyAx
NTo1MDo0OSAyMDAwDQpAQCAtNzIsNiArNzIsNyBAQA0KIGV4dGVybiBrbWVt
X2NhY2hlX3QJKmZpbHBfY2FjaGVwOw0KIGV4dGVybiBrbWVtX2NhY2hlX3QJ
KmRxdW90X2NhY2hlcDsNCiBleHRlcm4ga21lbV9jYWNoZV90CSpiaF9jYWNo
ZXA7DQorZXh0ZXJuIGttZW1fY2FjaGVfdAkqZnNfY2FjaGVwOw0KIA0KICNp
ZmRlZiBDT05GSUdfU01QDQogZXh0ZXJuIHVuc2lnbmVkIGxvbmcgc2xhYl9j
YWNoZV9kcmFpbl9tYXNrOw0KZGlmZiAtdXJOIC1YIGRvbnRkaWZmIGxpbnV4
L2tlcm5lbC9leGl0LmMgZnNjYWNoZS9rZXJuZWwvZXhpdC5jDQotLS0gbGlu
dXgva2VybmVsL2V4aXQuYwlNb24gQXVnICA3IDA4OjU3OjU4IDIwMDANCisr
KyBmc2NhY2hlL2tlcm5lbC9leGl0LmMJTW9uIEF1ZyAgNyAxNTo0ODoyNiAy
MDAwDQpAQCAtMjI5LDcgKzIyOSw3IEBADQogCQkJZHB1dChmcy0+YWx0cm9v
dCk7DQogCQkJbW50cHV0KGZzLT5hbHRyb290bW50KTsNCiAJCX0NCi0JCWtm
cmVlKGZzKTsNCisJCWttZW1fY2FjaGVfZnJlZShmc19jYWNoZXAsIGZzKTsN
CiAJfQ0KIH0NCiANCmRpZmYgLXVyTiAtWCBkb250ZGlmZiBsaW51eC9rZXJu
ZWwvZm9yay5jIGZzY2FjaGUva2VybmVsL2ZvcmsuYw0KLS0tIGxpbnV4L2tl
cm5lbC9mb3JrLmMJTW9uIEF1ZyAgNyAwODo1Nzo1OCAyMDAwDQorKysgZnNj
YWNoZS9rZXJuZWwvZm9yay5jCU1vbiBBdWcgIDcgMTU6NDk6MzggMjAwMA0K
QEAgLTMxOCw3ICszMTgsNyBAQA0KIA0KIHN0YXRpYyBpbmxpbmUgc3RydWN0
IGZzX3N0cnVjdCAqX19jb3B5X2ZzX3N0cnVjdChzdHJ1Y3QgZnNfc3RydWN0
ICpvbGQpDQogew0KLQlzdHJ1Y3QgZnNfc3RydWN0ICpmcyA9IGttYWxsb2Mo
c2l6ZW9mKCpvbGQpLCBHRlBfS0VSTkVMKTsNCisJc3RydWN0IGZzX3N0cnVj
dCAqZnMgPSBrbWVtX2NhY2hlX2FsbG9jKGZzX2NhY2hlcCwgR0ZQX0tFUk5F
TCk7DQogCS8qIFdlIGRvbid0IG5lZWQgdG8gbG9jayBmcyAtIHRoaW5rIHdo
eSA7LSkgKi8NCiAJaWYgKGZzKSB7DQogCQlhdG9taWNfc2V0KCZmcy0+Y291
bnQsIDEpOw0K
---1463811838-1964021912-965660704=:878--