linux-kernel - Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46AC4B97.5050708@gmail.com>
Date:	Sun, 29 Jul 2007 10:11:03 +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/28/2007 01:21 PM, Alan Cox wrote:

>> It is. Prefetched pages can be dropped on the floor without additional
>> I/O.
> 
> Which is essentially free for most cases. In addition your disk access 
> may well have been in idle time (and should be for this sort of stuff)

Yes. The swap-prefetch patch ensures that the machine (well, the VM) is very 
idle before it allows itself to kick in.

> and if it was in the same chunk as something nearby was effectively free 
> anyway.
> 
> Actual physical disk ops are precious resource and anything that mostly 
> reduces the number will be a win - not to stay swap prefetch is the right
> answer but accidentally or otherwise there are good reasons it may
> happen to help.
> 
> Bigger more linear chunks of writeout/readin is much more important I 
> suspect than swap prefetching.

Yes, I believe this might be an important point. Earlier I posted a dumb 
little VM thrasher:

http://lkml.org/lkml/2007/7/25/85

Contrived thing and all, but what it does do is show exactly how bad seeking 
all over swap-space is. If you push it out before hitting enter, the time it 
takes easily grows past 10 minutes (with my 768M) versus sub-second (!) when 
it's all in to start with.

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...

>> good overview of exactly how broken -mm can be at times. How many -mm users 
>> use it anyway? He himself said he's not convinced of usefulness having not 
> 
> I've been using it for months with no noticed problem. I turn it on
> because it might as well get tested. I've not done comparison tests so I
> can't comment on if its worth it.
> 
> Lots of -mm testers turn *everything* on because its a test kernel.

Okay.

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/