Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751432AbZLCEP5 (ORCPT ); Wed, 2 Dec 2009 23:15:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750976AbZLCEP4 (ORCPT ); Wed, 2 Dec 2009 23:15:56 -0500 Received: from mail-pw0-f42.google.com ([209.85.160.42]:65455 "EHLO mail-pw0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792AbZLCEP4 (ORCPT ); Wed, 2 Dec 2009 23:15:56 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=XFYK3T03VlPEI5EaO6NWOzTHPOJUxyZWw5Cb74afxyXpOtX2BkhY0Ng802FRPKKbPb PEiaiV+O92FEm9MB6DY1mCzED2nTCk8oNukVslGjsynn6hltI/Cn2G/WpSRJ8hoH/Dzu MwciWA+5iyEfSlgkzdHJELIAsNyO8DmBM6FpA= MIME-Version: 1.0 In-Reply-To: <4B0DDFDA.1030905@redhat.com> References: <2f11576a0911190636vd21069bv2fe4f22a57b3d333@mail.gmail.com> <4B0DDFDA.1030905@redhat.com> Date: Wed, 2 Dec 2009 23:16:02 -0500 X-Google-Sender-Auth: a541a389bfc4be3f Message-ID: Subject: Re: Linux 2.6.31 - very swap-happy with plenty of free RAM From: Dan Merillat To: Rik van Riel Cc: KOSAKI Motohiro , linux-kernel@vger.kernel.org, Norbert Preining , Tomasz Chmielewski , Sven-Haegar Koch , Dave Chinner Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1444 Lines: 34 > > Can you try out the patch from > http://lkml.org/lkml/2009/11/25/467 ? It's on the system now, I missed your reply for some reason. Stupid gmail. So far it's survived the 'open all in tabs' firefox test, which used to throw it into complete disarray, threw a 1gb file into tmpfs and it swapped out 150mb and didn't trash. It's running all the things I normally do in a day all at once, so far nothing, but it seems to take a while before things go pear-shaped. I'll give another update in a day or so. As an aside, why is swapin so incredibly slow compared to swapout? I mean, I understand why (pagefault->swapin *wait* run process new pagefault->swapin etc) but wouldn't much larger (4mb?) granularity of swap help with modern high-speed drives? I've seen a high of 2mb/sec swapin, and 100+mb/sec swapout. swapoff /dev/swap shows this very clearly - theoretically it should be "drop enough clean pages to fit everything into RAM, then read the swap partition in linearly". It's especially egregious in the case where a memory-hog has terminated, leaving more free RAM than swapped pages and swapoff still takes upwards of 10 minutes to complete what should be a 2-second disk read. -- 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/