Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Oct 2013 16:01:25 -0700
From:      Davide Italiano <davide@freebsd.org>
To:        RW <rwmaillists@googlemail.com>
Cc:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage?
Message-ID:  <CACYV=-EU86U6-q%2B-K1kVBPPTy_3vZJgjOf83hD9roqBYwY0YEw@mail.gmail.com>
In-Reply-To: <20131008233806.54bb0483@gumby.homeunix.com>
References:  <kvkvi7$iv7$1@ger.gmane.org> <20130828181228.0d3618dd@ernst.home> <CAF-QHFU80YC3W-k%2BTKM=y3JiVYi=1fp5CJjbCCk1y0VKXzcRQg@mail.gmail.com> <201309031507.33098.jhb@freebsd.org> <CACYV=-GZPbC03stS6PsihfJ688kbjna2-n0%2BPdctr3L9hvSvag@mail.gmail.com> <20131008063433.GA47506@x2.osted.lan> <CAJ-VmonngDnZuphdsSP%2B4qGaz4u%2B%2B-bxzqrP5pqi80OOj64GSQ@mail.gmail.com> <CACYV=-HYCNeuP70JdFBrG9vXXj-E6E%2BOHcJ7Ov-Dzazx_59cag@mail.gmail.com> <20131008233806.54bb0483@gumby.homeunix.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 8, 2013 at 3:38 PM, RW <rwmaillists@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@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-EU86U6-q%2B-K1kVBPPTy_3vZJgjOf83hD9roqBYwY0YEw>