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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0707281403510.32476@asgard.lang.hm>
Date:	Sat, 28 Jul 2007 14:06:50 -0700 (PDT)
From:	david@...g.hm
To:	Daniel Hazelton <dhazelton@...er.net>
cc:	Rene Herman <rene.herman@...il.com>,
	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 Sat, 28 Jul 2007, Daniel Hazelton wrote:

> 
> On Saturday 28 July 2007 04:55:58 david@...g.hm wrote:
>> On Sat, 28 Jul 2007, Rene Herman wrote:
>>> On 07/27/2007 09:43 PM, david@...g.hm wrote:
>>>>  On Fri, 27 Jul 2007, Rene Herman wrote:
>>>>>  On 07/27/2007 07:45 PM, Daniel Hazelton wrote:
>>
>> nobody is arguing that swap prefetch helps in the second cast.
>
> Actually, I made a mistake when tracking the thread and reading the code for
> the patch and started to argue just that. But I have to admit I made a
> mistake - the patches author has stated (as Rene was kind enough to point
> out) that swap prefetch can't help when memory is filled.

I stand corrected, thaks for speaking up and correcting your position.

>> what people are arguing is that there are situations where it helps for
>> the first case. on some machines and version of updatedb the nighly run of
>> updatedb can cause both sets of problems. but the nightly updatedb run is
>> not the only thing that can cause problems
>
> Solving the cache filling memory case is difficult. There have been a number
> of discussions about it. The simplest solution, IMHO, would be to place a
> (configurable) hard limit on the maximum size any of the kernels caches can
> grow to. (The only solution that was discussed, however, is a complex beast)

limiting the size of the cache is also the wrong thing to do in many 
situations. it's only right if the cache pushes out other data you care 
about, if you are trying to do one thing as fast as you can you really do 
want the system to use all the memory it can for the cache.

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/