On Mon, Mar 17, 2008 at 3:37 AM, Robert Collins
[EMAIL PROTECTED] wrote:
This reminds me, one of the things I was thinking heavily about a few
years ago was locality of reference in N-CPU situations. That is, making
sure we don't cause thrashing unnecessarily. For instance - given
chunking
Henrik Nordstrom wrote:
On Mon, 2008-03-10 at 15:32 +1300, Amos Jeffries wrote:
Is there a nice easy way in bzr of retrieving the -r # (of the
ancestor!) when the branch was last 'branched'/updated off its ancestor?
suitable for a bzr revert -r # ./Makefile.in (and others)
-r submit:
Hi Alex,
Alex Rousskov wrote:
On Sun, 2008-03-16 at 15:43 +, chtsanti wrote:
Update of cvs.devel.squid-cache.org:/cvsroot/squid/squid3/src
...
The xThrow function is similar to the old Throw function but in addition adds
an extra check to see if the carrent call can handle exceptions or
On Sun, 2008-03-16 at 21:54 -0600, Alex Rousskov wrote:
On Sun, 2008-03-16 at 02:55 +0100, Henrik Nordstrom wrote:
Cons:
- Not entirely sure how ICAP and ESI fits into the reply processing. But
I hope there is no problem..
The bzr branch can be found at
On Sun, 2008-03-16 at 21:54 -0600, Alex Rousskov wrote:
On Sun, 2008-03-16 at 02:55 +0100, Henrik Nordstrom wrote:
Cons:
- Not entirely sure how ICAP and ESI fits into the reply processing. But
I hope there is no problem..
The bzr branch can be found at
On Mon, 2008-03-17 at 11:00 +0900, Adrian Chadd wrote:
It'll also answer the question of is it worth having a slab allocator in
2008.
My gut feeling says yes, but only for very small allocations.
And my gut feeling is no, as there is better ways to manage memory which
stresses the allocator
On Sun, 2008-03-16 at 22:01 -0600, Alex Rousskov wrote:
Should not these formatting changes wait for the global astyle+wrapper
application, to minimize the number of times folks need to resolve
conflicts in their branches?
I think it's better to get this cleaned up soon, before there is too
On Tue, Mar 18, 2008, Henrik Nordstrom wrote:
On Mon, 2008-03-17 at 13:37 +1100, Robert Collins wrote:
it matter if process all the request on one CPU, or part on one part on
another? Given NUMA it clearly does matter, but how many folk run
squid/want to run squid on a NUMA machines?
On Tue, Mar 18, 2008, Henrik Nordstrom wrote:
Does it? Most mallocs I know about has details about the allocated
region just before the pointer (and optional red zone).
http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf
quote
Small allocations are segregated such that
