>azurlt, would you please test the patch attached? Thanks. This patch fixed the problem, i used 2.6.36.4 for testing. Do you need from me to test also other kernel versions or patches ? Thank you very much! ______________________________________________________________ > Od: "Changli Gao" <xiaosuo@xxxxxxxxx> > Komu: Eric Dumazet <eric.dumazet@xxxxxxxxx> > DÃtum: 07.04.2011 17:27 > Predmet: Re: Regression from 2.6.36 > > CC: "AmÃrico Wang" <xiyou.wangcong@xxxxxxxxx>, "Jiri Slaby" <jslaby@xxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, "Andrew Morton" <akpm@xxxxxxxxxxxxxxxxxxxx>, linux-mm@xxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, "Jiri Slaby" <jirislaby@xxxxxxxxx> >On Thu, Apr 7, 2011 at 8:13 PM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: >> Le jeudi 07 avril 2011 Ã 13:57 +0200, Eric Dumazet a Ãcrit : >> >>> We had a similar memory problem in fib_trie in the past Â: 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? > > >-- >Regards, >Changli Gao(xiaosuo@xxxxxxxxx) > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>