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
Small allocations are segregated such that each ru
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?
It would be great if bundlebunny could accept email votes without first
requiring an account. The rules on who may vode is not restricted to
just squid-core, even if votes from squid-core is more important.
My view regarding the voting procedure is that voting should be open to
all on squid-dev wh
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 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?
NUMA comes in many forms. SMP Opteron is a quote comm
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 alloca
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
> > http://www.henr
> 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
>> http://www.henriknordstrom.net/bzr/squid3/hno/largeresp/
>> (bzr only, no onlin
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
> > http://www.hen
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 excepti
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: sho
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
> chun
12 matches
Mail list logo
