[lkml]   [2001]   [Jan]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] dcache 2nd chance replacement
On Thu, Jan 04, 2001 at 02:23:53PM -0200, Rik van Riel wrote:
> > The dcache aging is mostly useful with _high_ VFS load like
> > updatedb in background. The logic is the same of the VM aging
> > (ask yourself when the VM aging is most useful: when there's
> > high VM load, like a `cp /dev/zero .`
> This is exactly the point where page aging alone isn't good
> enough and you need something like drop-behind...
> (yes, there IS a reason why we have drop_behind() and page
> deactivation in generic_file_write)

This is totally offtopic. We were _not_ talking about other algorithms. We
were _only_ talking about _when_ the 1 bit of aging I introduced with my
algorithm improves performance at max. My answer is that the max performance
improvement happens when there's the _highest_ VFS load in background and you
disagreed. Everything else has nothing to do with this our previous discussion
so your above reply partly still doesn't make sense to me.

Talking about the new topic you introduced above with your offtopic reply, I
think that for a thing like dcache 1 bit of aging is more than enough
(and btw, in my 2.4.x VM tree I put a 1 bit of aging also in the icache). In
case you didn't realized the frequency the dcache gets recycled completly is
much much much lower than the frequency something like the pagecache can be
recycled completly. So you have relatively plenty of time before the referenced
dentries gets collected.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:52    [W:1.405 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site