[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0707250132520.18679@asgard.lang.hm>
Date: Wed, 25 Jul 2007 01:33:45 -0700 (PDT)
From: david@...g.hm
To: Rene Herman <rene.herman@...il.com>
cc: Ray Lee <ray-lk@...rabbit.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
Jesper Juhl <jesper.juhl@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
ck list <ck@....kolivas.org>, Ingo Molnar <mingo@...e.hu>,
Paul Jackson <pj@....com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: -mm merge plans for 2.6.23
On Wed, 25 Jul 2007, david@...g.hm wrote:
> Subject: Re: -mm merge plans for 2.6.23
>
> On Wed, 25 Jul 2007, Rene Herman wrote:
>
>> On 07/25/2007 10:07 AM, david@...g.hm wrote:
>>
>> > On Wed, 25 Jul 2007, Rene Herman wrote:
>>
>> > > Something like this?
>>
>> [ ... ]
>>
>> > when the swap readahead is enabled does it make a significant
>> > difference
>> > in the time to do the random access?
>>
>> I don't use swap prefetch (nor -ck or -mm). If someone who has the patch
>> applied waits to hit enter until swap prefetch has prefetched it all back
>> in again, it certainly will.
>>
>> Swap prefetch's potential to do larger reads back from swapspace than a
>> random segfaulting app could well be very significant. Reads are dwarved
>> by seeks. If this program does what you wanted, please use it to show us.
>
> I haven't used swap prefetch either, the call was put out for what could be
> used to test the performance, and I was suggesting a test.
>
> if nobody else follows up on this I'll try to get some time to test it myself
> in a day or two.
this assumes that this isn't ruled an invalid test in the meantime.
in any case thanks for codeing this up so quickly.
David Lang
-
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