Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754699Ab1FODn2 (ORCPT ); Tue, 14 Jun 2011 23:43:28 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:59359 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753916Ab1FODn1 (ORCPT ); Tue, 14 Jun 2011 23:43:27 -0400 MIME-Version: 1.0 In-Reply-To: References: <1308097798.17300.142.camel@schen9-DESK> From: Linus Torvalds Date: Tue, 14 Jun 2011 20:42:27 -0700 Message-ID: Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex To: Tim Chen Cc: Peter Zijlstra , Andrew Morton , Hugh Dickins , KOSAKI Motohiro , Benjamin Herrenschmidt , David Miller , Martin Schwidefsky , Russell King , Paul Mundt , Jeff Dike , Richard Weinberger , Tony Luck , KAMEZAWA Hiroyuki , Mel Gorman , Nick Piggin , Namhyung Kim , ak@linux.intel.com, shaohua.li@intel.com, alex.shi@intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Rafael J. Wysocki" Content-Type: multipart/mixed; boundary=bcaec5014ba927443104a5b7f2ba Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4263 Lines: 77 --bcaec5014ba927443104a5b7f2ba Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 14, 2011 at 6:21 PM, Linus Torvalds wrote: > > Anyway, please check me if I'm wrong, but won't the "anon_vma->root" > be the same for all the anon_vma's that are associated with one > particular vma? > > The reason I ask [...] So here's a trial patch that moves the anon_vma locking one level up in the anon_vma_clone() call chain. It actually does allow the root to change, but has a WARN_ON_ONCE() if that ever happens. I *suspect* this will help the locking numbers a bit, but I'd like to note that it does this *only* for the anon_vma_clone() case, and the exact same thing should be done for the exit case too (ie the unlink_anon_vmas()). So if it does work it's still just one step on the way, and there would be more work along the same lines to possibly improve the locking further. The patch is "tested" in the sense that I booted the kernel and am running it right now (and compiled a kernel with it). But that's not a whole lot of actual real life testing, so caveat emptor. And I won't really even guarantee that the main problem locking-wise would be a long chain of "same_vma" anon-vma's that this does with just a single lock. So who knows - maybe it doesn't help at all. I suspect it's worth testing, though. Linus --bcaec5014ba927443104a5b7f2ba Content-Type: text/x-patch; charset=US-ASCII; name="patch.diff" Content-Disposition: attachment; filename="patch.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_goxqgqiz0 IG1tL3JtYXAuYyB8ICAgMTggKysrKysrKysrKysrKysrKy0tCiAxIGZpbGVzIGNoYW5nZWQsIDE2 IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbW0vcm1hcC5jIGIv bW0vcm1hcC5jCmluZGV4IDBlYjQ2M2VhODhkZC4uMjA2YzNmYjA3MmFmIDEwMDY0NAotLS0gYS9t bS9ybWFwLmMKKysrIGIvbW0vcm1hcC5jCkBAIC0yMDgsMTMgKzIwOCwxMSBAQCBzdGF0aWMgdm9p ZCBhbm9uX3ZtYV9jaGFpbl9saW5rKHN0cnVjdCB2bV9hcmVhX3N0cnVjdCAqdm1hLAogCWF2Yy0+ YW5vbl92bWEgPSBhbm9uX3ZtYTsKIAlsaXN0X2FkZCgmYXZjLT5zYW1lX3ZtYSwgJnZtYS0+YW5v bl92bWFfY2hhaW4pOwogCi0JYW5vbl92bWFfbG9jayhhbm9uX3ZtYSk7CiAJLyoKIAkgKiBJdCdz IGNyaXRpY2FsIHRvIGFkZCBuZXcgdm1hcyB0byB0aGUgdGFpbCBvZiB0aGUgYW5vbl92bWEsCiAJ ICogc2VlIGNvbW1lbnQgaW4gaHVnZV9tZW1vcnkuYzpfX3NwbGl0X2h1Z2VfcGFnZSgpLgogCSAq LwogCWxpc3RfYWRkX3RhaWwoJmF2Yy0+c2FtZV9hbm9uX3ZtYSwgJmFub25fdm1hLT5oZWFkKTsK LQlhbm9uX3ZtYV91bmxvY2soYW5vbl92bWEpOwogfQogCiAvKgpAQCAtMjI0LDE2ICsyMjIsMzAg QEAgc3RhdGljIHZvaWQgYW5vbl92bWFfY2hhaW5fbGluayhzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3Qg KnZtYSwKIGludCBhbm9uX3ZtYV9jbG9uZShzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKmRzdCwgc3Ry dWN0IHZtX2FyZWFfc3RydWN0ICpzcmMpCiB7CiAJc3RydWN0IGFub25fdm1hX2NoYWluICphdmMs ICpwYXZjOworCXN0cnVjdCBhbm9uX3ZtYSAqcm9vdCA9IE5VTEw7CiAKIAlsaXN0X2Zvcl9lYWNo X2VudHJ5X3JldmVyc2UocGF2YywgJnNyYy0+YW5vbl92bWFfY2hhaW4sIHNhbWVfdm1hKSB7CisJ CXN0cnVjdCBhbm9uX3ZtYSAqYW5vbl92bWEgPSBwYXZjLT5hbm9uX3ZtYSwgKm5ld19yb290ID0g YW5vbl92bWEtPnJvb3Q7CisKKwkJaWYgKG5ld19yb290ICE9IHJvb3QpIHsKKwkJCWlmIChXQVJO X09OX09OQ0Uocm9vdCkpCisJCQkJbXV0ZXhfdW5sb2NrKCZyb290LT5tdXRleCk7CisJCQlyb290 ID0gbmV3X3Jvb3Q7CisJCQltdXRleF9sb2NrKCZyb290LT5tdXRleCk7CisJCX0KKwogCQlhdmMg PSBhbm9uX3ZtYV9jaGFpbl9hbGxvYygpOwogCQlpZiAoIWF2YykKIAkJCWdvdG8gZW5vbWVtX2Zh aWx1cmU7CiAJCWFub25fdm1hX2NoYWluX2xpbmsoZHN0LCBhdmMsIHBhdmMtPmFub25fdm1hKTsK IAl9CisJaWYgKHJvb3QpCisJCW11dGV4X3VubG9jaygmcm9vdC0+bXV0ZXgpOwogCXJldHVybiAw OwogCiAgZW5vbWVtX2ZhaWx1cmU6CisJaWYgKHJvb3QpCisJCW11dGV4X3VubG9jaygmcm9vdC0+ bXV0ZXgpOwogCXVubGlua19hbm9uX3ZtYXMoZHN0KTsKIAlyZXR1cm4gLUVOT01FTTsKIH0KQEAg LTI4MCw3ICsyOTIsOSBAQCBpbnQgYW5vbl92bWFfZm9yayhzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3Qg KnZtYSwgc3RydWN0IHZtX2FyZWFfc3RydWN0ICpwdm1hKQogCWdldF9hbm9uX3ZtYShhbm9uX3Zt YS0+cm9vdCk7CiAJLyogTWFyayB0aGlzIGFub25fdm1hIGFzIHRoZSBvbmUgd2hlcmUgb3VyIG5l dyAoQ09XZWQpIHBhZ2VzIGdvLiAqLwogCXZtYS0+YW5vbl92bWEgPSBhbm9uX3ZtYTsKKwlhbm9u X3ZtYV9sb2NrKGFub25fdm1hKTsKIAlhbm9uX3ZtYV9jaGFpbl9saW5rKHZtYSwgYXZjLCBhbm9u X3ZtYSk7CisJYW5vbl92bWFfdW5sb2NrKGFub25fdm1hKTsKIAogCXJldHVybiAwOwogCg== --bcaec5014ba927443104a5b7f2ba-- -- 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/