Github user asfgit closed the pull request at:
https://github.com/apache/trafficserver/pull/489
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187939855
Updated to look for malloc_usable_size in autoconf and #ifdef for support.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187826715
@PSUdaemon said there is FreeBSD support for malloc_usable_size(), but not
for OmniOS.
Need to #ifdef for OmniOS.
---
If your project is set up for it
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187401764
@jpeach They are both counters.
@PSUdaemon Yes, old_size > new_size :)
---
If your project is set up for it, you can reply to this email and have your
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187355127
Updated to use malloc_usable_size()
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your proj
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187322502
> What do you mean by duplicates the memory tracking that is already done?
I just meant that the malloc implementation is already tracking the
allocation s
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187312131
@jpeach
Do you know what the overhead is on malloc_usable_size(). Maybe switching
over to that would be a better idea.
---
If your project is set up for
Github user dragon512 commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187311382
I take back what I said after talking to Bryan call.. This is using a
openssl lib callback API. So this looks good. The CPU is going to fine as long
as we are o
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187310269
@jpeach
I don't think it can get less ugly. I tried to clean it up as much as
possible.
What do you mean by duplicates the memory tracking that is
Github user dragon512 commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-187217377
I am not sure why we are using C++ and not using new to do this? We want to
track memory in Traffic server that is being used to alloc memory for OpenSSL (
ie n
Github user bgaff commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186991246
> Feels hacky though.
Maybe something like jemalloc would be better solution to this problem as
@jpeach has suggested.
---
If your project is set up for i
Github user PSUdaemon commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186988593
Duh. Sorry, looking too hard at malloc.
I have been trying to find macro we can use, but there isn't anything that
I can find that works well. This is h
Github user bgaff commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186980985
Ahh yes, you're correct @PSUdaemon . Nonetheless you cannot move the size_t
to the end because how would you find it given a raw pointer?
But @jpeach 's co
Github user PSUdaemon commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186979652
@bgaff,
I think the 8 byte thing is a glibc implementation detail. Also, [this
link](http://www.delorie.com/gnu/docs/glibc/libc_31.html
) suggests i
Github user bgaff commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186976913
@PSUdaemon malloc guarantees 8 byte alignment, fwiw. This still perseveres
8 byte alignment assuming sizeof(size_t) remains 8 bytes.
---
If your project is set up
Github user PSUdaemon commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186967151
@jpeach,
I can't speak to the relative ugliness of the code. It's fairly C-ish like
the rest of our memory related code.
I don't think the curr
Github user jpeach commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186952049
Are you sure there isn't a better way to do this?
- it is fairly ugly
- it duplicates the allocation size tracking the allocator is already doing
-
Github user bgaff commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186464921
What about the equivalents to posix_memalign?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If yo
Github user PSUdaemon commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186454905
:+1: This looks good to me.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186454283
I updated it with Phil's suggestion.
I can figure out later what to do about calling ats_malloc like function
within these tracking functions when I add
Github user bryancall commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/489#discussion_r53533502
--- Diff: lib/ts/ink_memory.cc ---
@@ -209,6 +210,46 @@ ats_mlock(caddr_t addr, size_t len)
return res;
}
+void *
+ats_track
Github user bryancall commented on the pull request:
https://github.com/apache/trafficserver/pull/489#issuecomment-186449042
I am planning on having and option for {{ats_malloc}} to call the track
functions in the future. Still thinking about how to do it cleanly.
---
If your projec
Github user PSUdaemon commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/489#discussion_r53530177
--- Diff: lib/ts/ink_memory.cc ---
@@ -209,6 +210,46 @@ ats_mlock(caddr_t addr, size_t len)
return res;
}
+void *
+ats_track
Github user PSUdaemon commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/489#discussion_r53529845
--- Diff: lib/ts/ink_memory.cc ---
@@ -209,6 +210,46 @@ ats_mlock(caddr_t addr, size_t len)
return res;
}
+void *
+ats_track
24 matches
Mail list logo
