From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763561AbZEHRTV (ORCPT ); Fri, 8 May 2009 13:19:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753384AbZEHRTN (ORCPT ); Fri, 8 May 2009 13:19:13 -0400 Received: from smtp3.ultrahosting.com ([74.213.175.254]:43337 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753323AbZEHRTM (ORCPT ); Fri, 8 May 2009 13:19:12 -0400 Date: Fri, 8 May 2009 13:18:55 -0400 (EDT) From: Christoph Lameter X-X-Sender: cl@qirst.com To: Elladan cc: Rik van Riel , Lee Schermerhorn , Peter Zijlstra , Wu Fengguang , Andrew Morton , "linux-kernel@vger.kernel.org" , "tytso@mit.edu" , "linux-mm@kvack.org" , Nick Piggin , Johannes Weiner , KOSAKI Motohiro Subject: Re: [PATCH -mm] vmscan: make mapped executable pages the first class citizen In-Reply-To: <20090508034054.GB1202@eskimo.com> Message-ID: References: <20090501123541.7983a8ae.akpm@linux-foundation.org> <20090503031539.GC5702@localhost> <1241432635.7620.4732.camel@twins> <20090507121101.GB20934@localhost> <1241705702.11251.156.camel@twins> <1241712000.18617.7.camel@lts-notebook> <4A03164D.90203@redhat.com> <20090508034054.GB1202@eskimo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 7 May 2009, Elladan wrote: > > Nobody (except you) is proposing that we completely disable > > the eviction of executable pages. I believe that your idea > > could easily lead to a denial of service attack, with a user > > creating a very large executable file and mmaping it. The amount of mlockable pages is limited via ulimit. We can already make the pages unreclaimable through mlock(). > I don't know of any distro that applies default ulimits, so desktops are > already susceptible to the far more trivial "call malloc a lot" or "fork bomb" > attacks. Plus, ulimits don't help, since they only apply per process - you'd > need a default mem cgroup before this mattered, I think. The point remains that the proposed patch does not solve the general problem that we encounter with exec pages of critical components of the user interface being evicted from memory. Do we have test data that shows a benefit? The description is minimal. Rik claimed on IRC that tests have been done. If so then the patch description should include the tests. Which loads benefit from this patch? A significant change to the reclaim algorithm also needs to have a clear description of the effects on reclaim behavior which is also lacking.