[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46AC9F2C.8090601@gmail.com>
Date: Sun, 29 Jul 2007 16:07:40 +0200
From: Rene Herman <rene.herman@...il.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: david@...g.hm, Daniel Hazelton <dhazelton@...er.net>,
Mike Galbraith <efault@....de>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Frank Kingswood <frank@...gswood-consulting.co.uk>,
Andi Kleen <andi@...stfloor.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Ray Lee <ray-lk@...rabbit.org>,
Jesper Juhl <jesper.juhl@...il.com>,
ck list <ck@....kolivas.org>, Paul Jackson <pj@....com>,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans
for 2.6.23]
On 07/29/2007 03:12 PM, Alan Cox wrote:
>> What are the tradeoffs here? What wants small chunks? Also, as far as
>> I'm aware Linux does not do things like up the granularity when it
>> notices it's swapping in heavily? That sounds sort of promising...
>
> Small chunks means you get better efficiency of memory use - large chunks
> mean you may well page in a lot more than you needed to each time (and
> cause more paging in turn). Your disk would prefer you fed it big linear
> I/O's - 512KB would probably be my first guess at tuning a large box
> under load for paging chunk size.
That probably kills my momentary hope that I was looking at yet another good
use of large soft-pages seeing as how 512K would be going overboard a bit
right? :-/
> More radically if anyone wants to do real researchy type work - how about
> log structured swap with a cleaner ?
Right over my head. Why does log-structure help anything?
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists