Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754181Ab1DGP1t (ORCPT ); Thu, 7 Apr 2011 11:27:49 -0400 Received: from mail-iw0-f174.google.com ([209.85.214.174]:48313 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751019Ab1DGP1s (ORCPT ); Thu, 7 Apr 2011 11:27:48 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=dd0bavnekXSf3cdwHdS9zp/mN6VXZOiWQWAXMg+YZG6IDobWGhjJKst+3+lNYMiP0j bD/7/pevht/i94j/yG0CnbP01r97P87MwJr1cG8SX3IBEloUGoPEtk5arKSd4mUux3/N 5A5O626ZKS26xmBgpl8ekzYLHChWBER4YQu/Y= MIME-Version: 1.0 In-Reply-To: <1302178426.3357.34.camel@edumazet-laptop> References: <20110315132527.130FB80018F1@mail1005.cent> <20110317001519.GB18911@kroah.com> <20110407120112.E08DCA03@pobox.sk> <4D9D8FAA.9080405@suse.cz> <1302177428.3357.25.camel@edumazet-laptop> <1302178426.3357.34.camel@edumazet-laptop> From: Changli Gao Date: Thu, 7 Apr 2011 23:27:26 +0800 Message-ID: Subject: Re: Regression from 2.6.36 To: Eric Dumazet Cc: =?ISO-8859-1?Q?Am=E9rico_Wang?= , Jiri Slaby , azurIt , linux-kernel@vger.kernel.org, Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Jiri Slaby Content-Type: multipart/mixed; boundary=0016368e1b8d65b44804a055c0e9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2496 Lines: 60 --0016368e1b8d65b44804a055c0e9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Apr 7, 2011 at 8:13 PM, Eric Dumazet wrote= : > Le jeudi 07 avril 2011 =E0 13:57 +0200, Eric Dumazet a =E9crit : > >> We had a similar memory problem in fib_trie in the past =A0: We force a >> synchronize_rcu() every XXX Mbytes allocated to make sure we dont have >> too much ram waiting to be freed in rcu queues. I don't think there is too much memory allocated by vmalloc to free. My patch should reduce the size of the memory allocated by vmalloc(). I think the real problem is kfree always returns the memory, whose size is aligned to 2^n pages, and more memory are used than before. > > This was done in commit c3059477fce2d956 > (ipv4: Use synchronize_rcu() during trie_rebalance()) > > It was possible in fib_trie because we hold RTNL lock, so managing > a counter was free. > > In fs case, we might use a percpu_counter if we really want to limit the > amount of space. > > Now, I am not even sure we should care that much and could just forget > about this high order pages use. In normal cases, only a few fds are used, the ftable isn't larger than one page, so we should use kmalloc to reduce the memory cost. Maybe we should set a upper limit for kmalloc() here. One page? azurlt, would you please test the patch attached? Thanks. --=20 Regards, Changli Gao(xiaosuo@gmail.com) --0016368e1b8d65b44804a055c0e9 Content-Type: application/octet-stream; name="x.diff" Content-Disposition: attachment; filename="x.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gm7ubqed0 ZGlmZiAtLWdpdCBhL2ZzL2ZpbGUuYyBiL2ZzL2ZpbGUuYwppbmRleCAwYmUzNDQ3Li45NjZiZjBj IDEwMDY0NAotLS0gYS9mcy9maWxlLmMKKysrIGIvZnMvZmlsZS5jCkBAIC00Myw5ICs0MywxMSBA QCBzdGF0aWMgaW5saW5lIHZvaWQgKmFsbG9jX2ZkbWVtKHVuc2lnbmVkIGludCBzaXplKQogewog CXZvaWQgKmRhdGE7CiAKLQlkYXRhID0ga21hbGxvYyhzaXplLCBHRlBfS0VSTkVMfF9fR0ZQX05P V0FSTik7Ci0JaWYgKGRhdGEgIT0gTlVMTCkKLQkJcmV0dXJuIGRhdGE7CisJaWYgKHNpemUgPD0g UEFHRV9TSVpFKSB7CisJCWRhdGEgPSBrbWFsbG9jKHNpemUsIEdGUF9LRVJORUx8X19HRlBfTk9X QVJOKTsKKwkJaWYgKGRhdGEgIT0gTlVMTCkKKwkJCXJldHVybiBkYXRhOworCX0KIAogCXJldHVy biB2bWFsbG9jKHNpemUpOwogfQo= --0016368e1b8d65b44804a055c0e9-- -- 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/