linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>,
	ck list <ck@vds.kolivas.org>,
	linux-mm@kvack.org, Paul Jackson <pj@sgi.com>
Subject: Re: [PATCH] mm: Implement Swap Prefetching v22
Date: Fri, 10 Feb 2006 01:10:36 +1100	[thread overview]
Message-ID: <43EB4D5C.8030603@yahoo.com.au> (raw)
In-Reply-To: <200602100047.09722.kernel@kolivas.org>

Con Kolivas wrote:
> On Friday 10 February 2006 00:29, Nick Piggin wrote:
> 
>>busy Con Kolivas wrote:
> 
> 
> busy? that's an interesting mua comment...
> 
> 

Oh I just added that.

>>- Looking a lot better from an impact-on-rest-of-vm code wise inspection.
> 
> 
> That's good to hear, thanks.
> 
> 
>>I got a couple of suggestions to make it even better.
>>
>>- I still have big reservations about it. For example the fact that if you
>>thrash memory and force everything to swap out, then exit your memory
>>hog, it won't do anything if you just happened to `cat bigfile > /dev/null`
>>
>>- Then, it has the potential to make *useful* swapping much less useful
>>(ie. it will page back in your unused programs and libraries, which will
>>kick out unmapped pagecache on desktop workloads).
>>
>>- It does not appear to necessarily solve the updatedb problem.
>>
>>- People complaining about their browser getting swapped out of their 1GB+
>>desktop systems due to a midnight cron run must be angering the VM gods.
>>I'd rather try to work out what to sacrifice in order to appease them
>>before sending another one up there to beat them into submission.
> 
> 
> I really don't want to go throwing out pagecache without some smart semantics 
> and then swap in random stuff that could be crap I agree. The answer to this 

Sure. It is not an easy problem space.

> is for the vm itself to have an ageing algorithm like the clockpro stuff 
> which does this in a smart way. It could certainly age away the updatedb 
> wrinkles and leave some free ram - which would help/be helped by prefetching.
> 
> I don't think I've ever said it fixes the updatedb debacle. Updatedb gets to 

I'm not sure that you ever did either, although I (and it seems at least
one other other in these recent threads) were perhaps under that impression
at one stage.

> rule another day, but that does not constitute every swap workload out there. 
> It helps my daily workloads, and as you might have missed, others have 
> reported demonstrable benefits (and not just the "it seems faster" type).
> 

Umm, yes I saw that. It is fairly plain that almost any VM change you could
possibly make that actually compiles is going to improve something.

I'm not denying any improvements. I'm pointing out that there are problems
too.

> 
>>Sorry to sound negative about it. 
> 
> 
> Well you're honest and that's worth respecting.
> 

Honesty shmonesty, I'm reviewing the thing :)

> 
>>Lucky for you nobody listens to me. 
> 
> 
> After some thought I've decided I ain't touching that one.
> 

Well at least you do.... Just to be sure, you did see my comments through
the code right?

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2006-02-09 14:10 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-09 12:39 Con Kolivas
2006-02-09 13:29 ` Nick Piggin
2006-02-09 13:47   ` Con Kolivas
2006-02-09 14:10     ` Nick Piggin [this message]
2006-02-09 14:12       ` Con Kolivas
2006-02-09 14:21     ` Nick Piggin
2006-02-09 22:48       ` Con Kolivas
2006-02-09 14:51   ` Con Kolivas
2006-02-10  1:04     ` Con Kolivas
2006-02-09 18:04   ` Nikita Danilov
2006-02-10  0:08     ` Con Kolivas
2006-02-09 15:12 ` Paul Jackson
2006-02-09 15:33   ` Con Kolivas
2006-02-10  0:51 ` KAMEZAWA Hiroyuki
2006-02-10  0:56   ` Con Kolivas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43EB4D5C.8030603@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=akpm@osdl.org \
    --cc=ck@vds.kolivas.org \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pj@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox