---1345348566-1446866437-944832782=:9019
Content-Type: TEXT/PLAIN; charset=US-ASCII
the attached small patch against 2.3.32-pre2 adds all pagecache blocks
that have established mappings to the buffer-cache hashlists (and can thus
can be looked up), including the swapcache. It works fine here and there
is no noticeable slowdown anywhere.
this does not fully solve the problem yet, what we need now is an agreed
on set of rules to access buffers that are in other caches as well (eg.
the pagecache).
Is it bad to synchronize access through the buffer-cache? I dont think so
and it's simple and straightforward. The disadvantage is that the
pagecache has to maintain the state of the buffer properly, which adds
some overhead. Eg if. a page sees a pagefault with write-access then all
underlying buffers have to be marked as 'permanent dirty'. Permament dirty
buffers are not written back by bdflush. This very same new buffer-state
could i believe be used by the journalling code too to tell other cache
users that a block is not to be written back, yet. In the typical 4k
blocksize case it's only one buffer that needs to be maintained, so the
cost doesnt look like to be big. There are probably other issues to be
solved as well, but this would be the main approach.
can you (or anyone else) see any problems with this approach?
-- mingo
---1345348566-1446866437-944832782=:9019
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="buffer-2.3.32-A0"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.3.96.991210083302.9019B@devserv.devel.redhat.com>
Content-Description:
LS0tIGxpbnV4L2ZzL2J1ZmZlci5jLm9yaWczCUZyaSBEZWMgMTAgMDU6NDM6
NTkgMTk5OQ0KKysrIGxpbnV4L2ZzL2J1ZmZlci5jCUZyaSBEZWMgMTAgMDU6
NTQ6NTggMTk5OQ0KQEAgLTUzMSw2ICs1MzEsOCBAQA0KIHsNCiAJc3RydWN0
IGJ1ZmZlcl9oZWFkICoqaGVhZCA9ICZoYXNoKGJoLT5iX2RldiwgYmgtPmJf
YmxvY2tucik7DQogDQorCWlmICghYnVmZmVyX21hcHBlZChiaCkpDQorCQlC
VUcoKTsNCiAJc3Bpbl9sb2NrKCZscnVfbGlzdF9sb2NrKTsNCiAJd3JpdGVf
bG9jaygmaGFzaF90YWJsZV9sb2NrKTsNCiAJX19oYXNoX2xpbmsoYmgsIGhl
YWQpOw0KQEAgLTEyMDgsOCArMTIxMCw4IEBADQogCQlpbml0X2J1ZmZlcihi
aCwgZW5kX2J1ZmZlcl9pb19hc3luYywgTlVMTCk7DQogCQliaC0+Yl9kZXYg
PSBkZXY7DQogCQliaC0+Yl9ibG9ja25yID0gYmxvY2s7DQotDQogCQlzZXRf
Yml0KEJIX01hcHBlZCwgJmJoLT5iX3N0YXRlKTsNCisJCWluc2VydF9pbnRv
X3F1ZXVlcyhiaCk7DQogCX0NCiAJdGFpbC0+Yl90aGlzX3BhZ2UgPSBoZWFk
Ow0KIAlnZXRfcGFnZShwYWdlKTsNCkBAIC0xODY4LDYgKzE4NzAsOCBAQA0K
IA0KIAkJaW5pdF9idWZmZXIoYmgsIGVuZF9idWZmZXJfaW9fYXN5bmMsIE5V
TEwpOw0KIAkJYXRvbWljX2luYygmYmgtPmJfY291bnQpOw0KKwkJaWYgKGJ1
ZmZlcl9tYXBwZWQoYmgpKQ0KKwkJCWluc2VydF9pbnRvX3F1ZXVlcyhiaCk7
DQogCQlhcnJbbnJdID0gYmg7DQogCQlucisrOw0KIAl9IHdoaWxlIChpKyss
IGlibG9jaysrLCAoYmggPSBiaC0+Yl90aGlzX3BhZ2UpICE9IGhlYWQpOw0K
---1345348566-1446866437-944832782=:9019--
-
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/