Call fo comments - raising vfs.ufs.dirhash_reclaimage?

[Davide Italiano]

On Tue, Oct 8, 2013 at 3:38 PM, RW <rwmaillists at googlemail.com> wrote:
> On Tue, 8 Oct 2013 13:32:58 +0200
> Davide Italiano wrote:
>
>> On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd <adrian at freebsd.org>
>> wrote:
>> > Hi,
>> >
>>
>> Hi Adrian,
>>
>> > Please try it out on a -10 VM with something RAM limited - say,
>> > 128mb w/ GENERIC. See how it behaves.
>
> Be aware that any test that doesn't cause vfs.ufs.dirhash_lowmemcount
> to increment isn't testing the change at all.
>
>
>> This is not supposed to hit 10-STABLE, at least not before proper
>> review. This is the reason why it was proposed on mailing lists. Also,
>> if you read the patch you'll end up with realizing this should behave
>> better on low memory environment because it unconditionally cleans 10%
>> of the cache every time.
>
> The current version deletes anything older than the time limit and if
> this doesn't reclaim 10% it makes a second pass through the list until
> the target is met.
>
> Your version tries to delete 10% (or whatever) by looping around the
> list until this is achieved. And if there aren't enough unlocked
> entries it will loop  indefinitely until there are. I hope you know
> what you are doing because that looks very wrong.
>

Hi (RW..?),

This could be probably changed -- from what | see even under high
memory pressure this wasn't a problem but all in all I agree with you
that we shouldn't loop forever but limit the number of pass on the
list to a somewhat constant number, to prevent pathological cases.

> The original version looks better to me given that it already tries to
> free a minimum of 10%. The low-memory handler is called under very low
> memory conditions when the system is probably thrashing or even on the
> verge of killing processes. Holding on to entries that haven't been
> used for a minute seems like a luxury.
>
>> Previous changes in this area just did the
>> opposite keeping a lot more of memory around.
>
> I don't believe that's true. Under most circustances the existing
> scheme free more memory. The only case when yours frees more is when 90%
> of the entries are locked.

Well, no. Here you can set the threshold to a more aggressive value so
that you reclaim more memory every time. Note that this was not
possible in the previous version, so, if you could have a situation
where all your cache entries were not touched for 15 or even 30
seconds they would have kept around, and you can destroy up to 10% of
them everytime lowmem event is called.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare