From: Daniel Gorsulowski <daniel.gorsulowski@esd.eu>
To: "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: [ISSUE] Memleak in LED sysfs on heavy usage
Date: Mon, 12 Sep 2016 10:50:52 +0200 [thread overview]
Message-ID: <d3cf2089-794f-f156-c5b9-ed749076c0dd@esd.eu> (raw)
Hello!
Please consider if I made something wrong, sending this issue. This is
my first contact to the LKML.
By mistake, I accessed an LED via /sys/class/leds subsystem very fast in
an user application. I figured out, that the free user memory decreased
constantly. So I tried to analyze the Problem and wrote a litte script:
#!/bin/sh
while [ 1 ]; do
echo 1 > /sys/class/leds/2a_service_yellow/brightness
echo 0 > /sys/class/leds/2a_service_yellow/brightness
done
And voila, I was able to reproduce the problem.
So I add a bit more debugging:
#!/bin/sh
cnt=0
while [ 1 ]; do
if [ `expr $cnt % 1000` -eq 0 ]; then
free | grep Mem: | cut -d' ' -f25
fi
echo 1 > /sys/class/leds/2a_service_yellow/brightness
echo 0 > /sys/class/leds/2a_service_yellow/brightness
let "cnt++"
done
And huh? No memory is eaten anymore. So it looks like, the problem only
occours on heavy (fast) usage of /sys/class/leds subsystem.
I rewrote the script and toggled a GPIO pin, but there was no problem
recognizable.
Some details about my test environment:
Hardware: Ti Sitara AM3357ZCZ with 128MiB memory
Kernel: vanilla 4.6
The relevant part of my .dts:
#include "am33xx.dtsi"
/ {
...
cpus {
cpu@0 {
cpu0-supply = <&dcdc2_reg>;
operating-points = <
/* kHz uV */
800000 1300000
600000 1112000
300000 969000
>;
};
};
memory {
device_type = "memory";
reg = <0x80000000 0x08000000>; /* 128 Mib */
};
...
leds {
pinctrl-names = "default";
pinctrl-0 = <&user_leds_s0>;
compatible = "gpio-leds";
...
led2 {
label = "2a_service_yellow";
gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "2a_service_yellow";
default-state = "off";
};
...
};
...
};
&am33xx_pinmux {
pinctrl-names = "default";
pinctrl-0 = <&gpio_misc_pins>;
...
user_leds_s0: user_leds_s0 {
pinctrl-single,pins = <
...
0x24 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /* (T10) gpmc_ad9.gpio0[23] */
>;
};
...
};
...
Kind regards
Daniel
next reply other threads:[~2016-09-12 8:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20160912085832eucas1p1e7332f761e5e0cb764a6831b9a519b70@eucas1p1.samsung.com>
2016-09-12 8:50 ` Daniel Gorsulowski [this message]
2016-09-13 7:16 ` [ISSUE] Memleak in LED sysfs on heavy usage Jacek Anaszewski
2016-09-16 7:31 ` Jacek Anaszewski
2016-09-16 8:15 ` Daniel Gorsulowski
2016-09-16 11:25 ` Jacek Anaszewski
2016-09-16 12:08 ` Daniel Gorsulowski
2016-09-16 13:41 ` Jacek Anaszewski
2016-09-16 14:06 ` Greg KH
2016-09-16 14:32 ` Jacek Anaszewski
2016-09-16 14:39 ` Greg KH
2016-09-16 18:49 ` Jacek Anaszewski
2016-09-16 19:44 ` Greg KH
2016-09-16 21:08 ` Jacek Anaszewski
2016-09-19 8:35 ` Jacek Anaszewski
2016-09-19 4:35 ` Daniel Gorsulowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d3cf2089-794f-f156-c5b9-ed749076c0dd@esd.eu \
--to=daniel.gorsulowski@esd.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.