Sorry for the delay in reply. Traveling.
I'm afraid that our next step of extensive testing in production with
jemalloc but without ATS free lists has been delayed due to packaging
transitions. Now we are in a good place to be doing that testing, and it
will be a goal for Fei in Q1.
On Wed, Dec
Ah, yes I recall now. Did we ever take the next step here like was
mentioned in the comments?
On Wed, Dec 12, 2018 at 5:45 PM Susan Hinrichs wrote:
> I believe it came in on https://github.com/apache/trafficserver/pull/3246
>
> On Wed, Dec 12, 2018 at 7:04 PM Phil Sorber wrote:
>
> > Can you po
I believe it came in on https://github.com/apache/trafficserver/pull/3246
On Wed, Dec 12, 2018 at 7:04 PM Phil Sorber wrote:
> Can you point me to the PR/commit on github?
>
> Thanks.
>
> On Wed, Dec 12, 2018 at 4:51 PM SUSAN HINRICHS wrote:
>
> > Fei committed the don't dump fix for jemalloc a
Can you point me to the PR/commit on github?
Thanks.
On Wed, Dec 12, 2018 at 4:51 PM SUSAN HINRICHS wrote:
> Fei committed the don't dump fix for jemalloc a few months back.
>
> On Wed, Dec 12, 2018, 4:46 PM Leif Hedstrom
> >
> >
> > > On Dec 12, 2018, at 4:42 PM, Phil Sorber wrote:
> > >
> >
Fei committed the don't dump fix for jemalloc a few months back.
On Wed, Dec 12, 2018, 4:46 PM Leif Hedstrom
>
> > On Dec 12, 2018, at 4:42 PM, Phil Sorber wrote:
> >
> > The problem was that we were using jemalloc as a drop in replacement for
> > malloc/free. The DONT_DUMP issue is easy to addr
> On Dec 12, 2018, at 4:42 PM, Phil Sorber wrote:
>
> The problem was that we were using jemalloc as a drop in replacement for
> malloc/free. The DONT_DUMP issue is easy to address when using the jemalloc
> APIs directly. Perhaps someone will make me a salami sandwich and I will
> write the pa
The problem was that we were using jemalloc as a drop in replacement for
malloc/free. The DONT_DUMP issue is easy to address when using the jemalloc
APIs directly. Perhaps someone will make me a salami sandwich and I will
write the patch over the holiday break. Whiskey wouldn't hurt either.
On We
On Wed, Dec 12, 2018 at 8:49 AM Alan Carroll
wrote:
> Pushkar - based on my understanding of Fei's experiments, the issue was
> doing the DONT_DUMP marking, which would cause problems with jemalloc.
> That's part of the effort of getting jemalloc ready.
>
> Walt - I've read through your code and
Pushkar - based on my understanding of Fei's experiments, the issue was
doing the DONT_DUMP marking, which would cause problems with jemalloc.
That's part of the effort of getting jemalloc ready.
Walt - I've read through your code and I don't really the benefits. It's
definitely cleaner code, but
The freelist can be used with jemalloc, but the thought/theory is that you can
turn off the freelist and use jemalloc and get similar performance. This needs
to be validated.
-Bryan
> On Dec 11, 2018, at 3:18 PM, Walt Karas wrote:
>
> I thought jemalloc is used as a drop-in replacement for th
Yeah I am curious too, how could it make ATS unstable. It's a pretty
popular library.
Maybe ATS has a mismatch of malloc/free etc.something that is masked by the
free list?
On Tue, Dec 11, 2018 at 3:19 PM Walt Karas wrote:
> I thought jemalloc is used as a drop-in replacement for the standard li
I thought jemalloc is used as a drop-in replacement for the standard lib
heap functions / operators. So how can the freelist stuff not work with it?
On Tue, Dec 11, 2018 at 4:48 PM Bryan Call wrote:
> There is no point in cleaning up the code if the plan is to not use it and
> remove it from ou
There is no point in cleaning up the code if the plan is to not use it and
remove it from our codebase. Work should be done on proving that jemalloc is
valid alternative.
If jemalloc doesn’t prove to workout, then we might look at cleaning up the
freelist.
-Bryan
> On Dec 10, 2018, at 5:42 P
As far as one can tell is a big limitation with code like:
#if (defined(__i386__) || defined(__arm__) || defined(__mips__)) &&
> (SIZEOF_VOIDP == 4)
>
> #define FREELIST_POINTER(_x) (_x).s.pointer
>
> #define FREELIST_VERSION(_x) (_x).s.version
>
> #define SET_FREELIST_POINTER_VERSION(_x, _p, _v)
> On Dec 10, 2018, at 10:29 AM, SUSAN HINRICHS wrote:
>
> Based on Fei's measurements, the ATS freelists provide no benefit over
> jemalloc. We are now in a position to do larger tests over our production
> installs.
Agreed, that was generally what I noticed too, except, I could not get ATS
Based on Fei's measurements, the ATS freelists provide no benefit over
jemalloc. We are now in a position to do larger tests over our production
installs.
On Mon, Dec 10, 2018, 10:10 AM James Peach
>
> > On Dec 10, 2018, at 9:08 AM, Walt Karas wrote:
> >
> > It's a matter of intuition how much
Fei's being doing tests like this. But do we have a way of comparing
two executables with realistic traffic and the same traffic twice?
On Mon, Dec 10, 2018 at 12:10 PM James Peach wrote:
>
>
>
> > On Dec 10, 2018, at 9:08 AM, Walt Karas wrote:
> >
> > It's a matter of intuition how much free li
> On Dec 10, 2018, at 9:08 AM, Walt Karas wrote:
>
> It's a matter of intuition how much free lists improve TS performance,
Is it? Can you benchmark with the -f and -F flags to verify the effect of free
lists and the proxy allocator?
J
It's a matter of intuition how much free lists improve TS performance,
I'm not so sure it's worth it either. But I do feel it's clear that,
if we are going to to use freelists, my implementation is strongly
preferable. Based on the preferability of clear, minimal interfaces
and lack of unnecessar
I agree, there are other problems that would take priority over reimplementing
the free list.
-Bryan
> On Dec 8, 2018, at 10:59 AM, Leif Hedstrom wrote:
>
>
>
>> On Dec 7, 2018, at 18:10, Walt Karas wrote:
>>
>> How does one migrate improper code properly?
>
> You get rid of it. I’d arg
> On Dec 7, 2018, at 18:10, Walt Karas wrote:
>
> How does one migrate improper code properly?
You get rid of it. I’d argue that what we have works fine, has worked fine for
years and your are replacing with something that we will replace anyways.
Focus on real problems IMO.
— Leif
>> O
How does one migrate improper code properly?
On Fri, Dec 7, 2018 at 5:54 PM Leif Hedstrom wrote:
>
>
>
> > On Dec 7, 2018, at 1:02 PM, Walt Karas wrote:
> >
> > It's the same general idea as the current free lists, but with a
> > better, cleaner implementation. If there are a lot of smaller dyna
> On Dec 7, 2018, at 1:02 PM, Walt Karas wrote:
>
> It's the same general idea as the current free lists, but with a
> better, cleaner implementation. If there are a lot of smaller dynamic
> objects with short lifetimes, it will reduce thread blocking on the
> heap mutex, block coalescing, an
It's the same general idea as the current free lists, but with a
better, cleaner implementation. If there are a lot of smaller dynamic
objects with short lifetimes, it will reduce thread blocking on the
heap mutex, block coalescing, and relatively complex changes to the
data structure of free bloc
What problem does solve? Does it make things faster?
— Leif
> On Dec 7, 2018, at 09:27, Walt Karas wrote:
>
> This doesn't conflict with those efforts, and is much easier to do.
>> On Thu, Dec 6, 2018 at 6:56 PM Leif Hedstrom wrote:
>>
>> I thought the efforts were to be focused on getting
This doesn't conflict with those efforts, and is much easier to do.
On Thu, Dec 6, 2018 at 6:56 PM Leif Hedstrom wrote:
>
> I thought the efforts were to be focused on getting jemalloc optimized with
> their concepts of arenas and NUMA affinity and thread ware allocations?
>
> — Leif
>
> > On Dec
I thought the efforts were to be focused on getting jemalloc optimized with
their concepts of arenas and NUMA affinity and thread ware allocations?
— Leif
> On Dec 6, 2018, at 15:02, Walt Karas wrote:
>
> Would it be desirable for ATS to use this (cleaner) version of free lists?
>
> https://
27 matches
Mail list logo
