<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Apr 29, 2017 11:27 AM, "Timothy Arceri" <<a href="mailto:tarceri@itsqueeze.com">tarceri@itsqueeze.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 29/04/17 18:44, Marek Olšák wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">
<br>
<br>
On Apr 29, 2017 4:20 AM, "Michel Dänzer" <<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a> <mailto:<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>>> wrote:<br>
<br>
On 28/04/17 09:11 PM, Marek Olšák wrote:<br>
> On Thu, Apr 27, 2017 at 8:47 AM, Michel Dänzer<br></div><div class="quoted-text">
<<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a> <mailto:<a href="mailto:michel@daenzer.net" target="_blank">michel@daenzer.net</a>>> wrote:<br>
>> On 27/04/17 10:15 AM, Timothy Arceri wrote:<br>
>>> Modern disks are extremely large and are only going to get bigger.<br>
>>> Usage has shown frequent Mesa upgrades can result in the cache<br>
>>> growing very fast i.e. wasting a lot of disk space unnecessarily.<br>
>>><br>
>>> 5% seems like a more reasonable default.<br>
>>><br>
>>> Cc: "17.1" <<a href="mailto:mesa-stable@lists.freedesktop.org" target="_blank">mesa-stable@lists.freedesktop<wbr>.org</a><br></div>
<mailto:<a href="mailto:mesa-stable@lists.freedesktop.org" target="_blank">mesa-stable@lists.free<wbr>desktop.org</a>>><div class="elided-text"><br>
>>> ---<br>
>>> src/util/disk_cache.c | 4 ++--<br>
>>> 1 file changed, 2 insertions(+), 2 deletions(-)<br>
>>><br>
>>> diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c<br>
>>> index d9de8ef..9fd7b96 100644<br>
>>> --- a/src/util/disk_cache.c<br>
>>> +++ b/src/util/disk_cache.c<br>
>>> @@ -324,24 +324,24 @@ disk_cache_create(const char *gpu_name,<br>
const char *timestamp)<br>
>>> case '\0':<br>
>>> case 'G':<br>
>>> case 'g':<br>
>>> default:<br>
>>> max_size *= 1024*1024*1024;<br>
>>> break;<br>
>>> }<br>
>>> }<br>
>>> }<br>
>>><br>
>>> - /* Default to 1GB or 10% of filesystem for maximum cache<br>
size. */<br>
>>> + /* Default to 1GB or 5% of filesystem for maximum cache<br>
size. */<br>
>>> if (max_size == 0) {<br>
>>> statvfs(path, &vfs);<br>
>>> - max_size = MAX2(1024*1024*1024, vfs.f_blocks *<br>
vfs.f_bsize / 10);<br>
>>> + max_size = MAX2(1024*1024*1024, vfs.f_blocks *<br>
vfs.f_bsize / 20);<br>
>>> }<br>
>><br>
>> 5% can still be quite a lot (what if every library on the system<br>
tried<br>
>> using that much for itself?). How about 1%?<br>
><br>
> The argument is flawed. My ccache uses 12% (26.8 GB) of my disk, and<br>
> I'm not saying "what if every small app used that much...". There<br>
is a<br>
> very good reason for that size with my use case.<br>
<br>
ccache defaults to a maximum cache size of 5G. You had to explicitly<br>
allow it to use more; you can do the same with the Mesa shader cache.<br>
<br>
<br>
> It certainly makes sense to use 5% of the filesystem for Mesa.<br>
<br>
I don't agree for the default, especially as long as the Mesa shader<br>
cache only actually makes use of about 10-20% of the disk space<br>
allocated for it, due to having a huge number of tiny files. (ccache in<br>
contrast actually makes good use of the disk space allocated for it,<br>
because its cache entries are normally larger than a single disk block)<br>
<br>
<br>
That's a good point. I didn't think of that. Still, if one game evicts all entries, the cache may be almost as good as disabled.<br>
</div></blockquote>
<br>
I'm happy for the default limit to be raised from 1GB. However as I replied in the other thread using a percentage is not a good idea at this stage IMO.<br>
<br>
For the majority of use cases 1GB should be more than enough. Deus Ex is very shader heavy and when compressed it was only taking up ~30MB, so I wouldn't be to worried about entries getting evicted unless there is something on the system generating a boat load of unique shaders.</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">30MB is actually useful information that puts everything into perspective. Thanks.</div><div dir="auto"><br></div><div dir="auto">Marek</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Marek<br>
<br>
<br>
<br>
--<br>
Earthling Michel Dänzer | <a href="http://www.amd.com" rel="noreferrer" target="_blank">http://www.amd.com</a><br>
Libre software enthusiast | Mesa and X developer<br>
<br>
<br>
</blockquote>
</div></blockquote></div><br></div></div></div>