>
>
> that isn't what i meant. i don't care about runtime config options but
> about (1) the code and (2) build time control. fs should remain in the
> source and memcache should be an additional configure flag which allows
> the user to select it at runtime.
>
Ah, ok then we are on the same page
Den 2015-12-07 kl. 04:48, skrev Mike Frysinger:
> On 02 Dec 2015 20:16, Pierre Tardy wrote:
>>> i don't think getting rid out of the fs makes sense, but having memcache
>>> be available dynamically as an additional layer sounds fine..
>>
>> It does make a lot of sense for me as I have a high perfor
On 02 Dec 2015 20:16, Pierre Tardy wrote:
> > i don't think getting rid out of the fs makes sense, but having memcache
> > be available dynamically as an additional layer sounds fine.
>
> It does make a lot of sense for me as I have a high performance network,
> which is faster than local harddriv
Pierre Tardy wrote:
>> Here is such an attempt, to keep *both* features available:
>> https://github.com/itensionanders/ccache/tree/memcached-only
>
> I like it very much. I think it adds great value for ccache, and to my
> old memcached-only attempt.
Yeah, if it doesn't bloat the code ba
Hi,
I like it very much. I think it adds great value for ccache, and to my old
memcached-only attempt.
I did not realize the use for moxi also as a connection "keep-alive"
mechanism, and a way to hide the syn-ack latency overhead. I think this is
what you mean by "avoid some of the network overhe
> The option to switch the to_cache/from_cache can be made available
> separately, like it was in your PR. But it can use another config ?
> Probably needs some updating and refactoring, and it would be nice
> to try and keep the code duplication between them to a minimum...
>
> i.e. between the cu
Pierre Tardy wrote:
>
> i don't think getting rid out of the fs makes sense, but having memcache
> be available dynamically as an additional layer sounds fine.
>
> It does make a lot of sense for me as I have a high performance network,
> which is faster than local harddrive. So I would ins
>
>
> i don't think getting rid out of the fs makes sense, but having memcache
> be available dynamically as an additional layer sounds fine.
>
It does make a lot of sense for me as I have a high performance network,
which is faster than local harddrive. So I would insist on keeping an
option for
On 01 Dec 2015 21:59, Anders Björklund wrote:
> Pierre Tardy made a PR (https://github.com/jrosdahl/ccache/pull/30)
> to replace the filesystem ("fs") cache with memcached altogether.
>
> We have gone with a different approach, to use memcached only as a
> secondary cache - while preserving the pr
Hi all!
While the idea of using memcached with ccache is nothing new (*),
it seems to be more popular now with more memory being available...
* https://lists.samba.org/archive/ccache/2010q4/000686.html
https://lists.samba.org/archive/ccache/2013q2/001120.html
Pierre Tardy made a PR (https://g
Wilson Snyder wrote:
>>I think it would be a pretty interesting idea.
>>
>>Obviously you would need to trust all the other clients writing into
>>the cache, but that's probably feasible in this environment.
>>
>>A shared cache kept entirely in ram might grow fairly big, but it's
>>not so expensiv
>> We have about 100 machines, with about 400 cores - a mix of
>> older 2 socket up to modern 12 core systems. Compiles are
>> ~~10% of the work load. The NFS server with CCACHE_DIR has
>> 6 RAID-5 disks; it does other things too, not just ccache.
>> We decided to bond 4 ethernet ports into the
On 25-11-2010 13:08, Wilson Snyder wrote:
We have about 100 machines, with about 400 cores - a mix of
older 2 socket up to modern 12 core systems. Compiles are
~~10% of the work load. The NFS server with CCACHE_DIR has
6 RAID-5 disks; it does other things too, not just ccache.
We decided to bo
>> If you already are, are you really doing enough writes to
>> swamp a NFS cache server? It probably requires hundreds of
>> compiling clients; since we have over a hundred here and
>> don't see a bottleneck - with a single well performing NFS
>> server.
>
>In our case we're talking about 25 sha
On 25-11-2010 11:17, Wilson Snyder wrote:
Why don't you just put the cache on a NFS (/CIFS) mounted
volume? With the most recent version this should work well.
In our case the biggest compilation issues we have is from Windows and
not linux.
My thought until now has been that there was a lo
>On 25 November 2010 00:52, Henrik Goldman wrote:
>> Hello,
>>
>> I wonder if anyone ever considered using memcached as an optional backend
>> for ccached?
>>
>> Here is the issue we're considering. In our C++ project we have a number of
>> developers doing their own local compilations. When any u
On 25 November 2010 00:52, Henrik Goldman wrote:
> Hello,
>
> I wonder if anyone ever considered using memcached as an optional backend
> for ccached?
>
> Here is the issue we're considering. In our C++ project we have a number of
> developers doing their own local compilations. When any updates o
Hello,
I wonder if anyone ever considered using memcached as an optional
backend for ccached?
Here is the issue we're considering. In our C++ project we have a number
of developers doing their own local compilations. When any updates
occurs (e.g. they update to the latest source code from sc
18 matches
Mail list logo
