On 24 July 2018 at 12:05, Bruce Merry wrote:
> To reproduce:
> 1. Start cadvisor running. I use the 0.30.2 binary from Github, and
> run it with sudo ./cadvisor-0.30.2 --logtostderr=true
> 2. Run the Python 3 script below, which repeatedly creates a cgroup,
> enters it, stats s
Bruce
--
Bruce Merry
Senior Science Processing Developer
SKA South Africa
1)
is almost unchanged at around 18ms (was 20ms, but there were slightly
more cgroups as well), compared to the almost 4x speedup you're seeing
in your test.
Regards
Bruce
--
Bruce Merry
Senior Science Processing Developer
SKA South Africa
On 18 July 2018 at 19:40, Bruce Merry wrote:
>> Yes, very easy to produce zombies, though I don't think kernel
>> provides any way to tell how many zombies exist on the system.
>>
>> To create a zombie, first create a memcg node, enter that memcg,
>> create
On 18 July 2018 at 20:13, Shakeel Butt wrote:
> On Wed, Jul 18, 2018 at 10:58 AM Bruce Merry wrote:
> Yes, if there is no memory pressure such memory can stay around.
>
> On your production machine, before deleting memory containers, you can
> try force_empty to reclaim such m
On 18 July 2018 at 19:48, Shakeel Butt wrote:
> On Wed, Jul 18, 2018 at 10:40 AM Bruce Merry wrote:
>> > Yes, very easy to produce zombies, though I don't think kernel
>> > provides any way to tell how many zombies exist on the system.
>> >
>> > T
On 18 July 2018 at 17:49, Shakeel Butt wrote:
> On Wed, Jul 18, 2018 at 8:37 AM Bruce Merry wrote:
>> That sounds promising. Is there any way to tell how many zombies there
>> are, and is there any way to deliberately create zombies? If I can
>> produce zombies that might g
On 18 July 2018 at 17:26, Shakeel Butt wrote:
> On Wed, Jul 18, 2018 at 7:29 AM Bruce Merry wrote:
> It seems like you are using cgroup-v1. How many nodes are there in
> your memcg tree and also how many cpus does the system have?
>From my original email: "there are 106 mem
oes every child cgroup contribute to the stat_show cost of
its parent or does it have to have some non-trivial variation from its
parent?
Thanks
Bruce
--
Bruce Merry
Senior Science Processing Developer
SKA South Africa
On 18 July 2018 at 12:42, Michal Hocko wrote:
> [CC some more people]
>
> On Tue 17-07-18 21:23:07, Andrew Morton wrote:
>> (cc linux-mm)
>>
>> On Tue, 3 Jul 2018 08:43:23 +0200 Bruce Merry wrote:
>>
>> > Hi
>> >
>> > I've
use, or even better, how to
prevent it happening?
Thanks
Bruce
--
Bruce Merry
Senior Science Processing Developer
SKA South Africa
Commit-ID: e17fdaeaec066c725f73cd3cda1feae52b2646f5
Gitweb: http://git.kernel.org/tip/e17fdaeaec066c725f73cd3cda1feae52b2646f5
Author: Bruce Merry
AuthorDate: Thu, 15 Jan 2015 11:20:22 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Sun, 22 Feb 2015 23:10:56 -0300
perf bench
This was causing the destination instead of the source to be filled.
As a result, the source was typically all mapped to one zero page,
and hence very cacheable.
Signed-off-by: Bruce Merry
---
tools/perf/bench/mem-memcpy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
mem(&src, &dst, len);
+memcpy_alloc_mem(&dst, &src, len);
if (prefault)
fn(dst, src, len);
--
1.9.1
--
Bruce Merry
Senior Science Processing Developer
SKA South Africa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
nt into daemon state and refused to die, even with kill -9. I'm
guessing that this means the problem is in either the CD-ROM code or the UDF
code, but it might be unrelated.
I've attached the output from ksymoops.
B4N
Bruce
/------
15 matches
Mail list logo
