All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Daniel Gorsulowski <daniel.gorsulowski@esd.eu>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [ISSUE] Memleak in LED sysfs on heavy usage
Date: Fri, 16 Sep 2016 13:25:07 +0200	[thread overview]
Message-ID: <4d51014d-c8fa-4687-cae8-1a8dd0f79beb@samsung.com> (raw)
In-Reply-To: <d78a668f-f2fa-da5e-7895-c3fc0ef272e7@esd.eu>

On 09/16/2016 10:15 AM, Daniel Gorsulowski wrote:
> Hi Jacek,
>
> Am 16.09.2016 um 09:31 schrieb Jacek Anaszewski:
>> Hi Daniel,
>>
>> On 09/12/2016 10:50 AM, Daniel Gorsulowski wrote:
>>> 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.
>>
>> I've been unable to reproduce the problem with leds-aat1290 driver
>> and Samsung M0 board. It must be driver specific issue.
>> What driver did you use?
>>
> I defined LEDS_GPIO and so I'm using leds-gpio driver.
> danielg@debby:~/opt/prj/ti-linux-kernel$ cat .config | grep LEDS | grep
> -v "^# "
> CONFIG_INPUT_LEDS=y
> CONFIG_NEW_LEDS=y
> CONFIG_LEDS_CLASS=y
> CONFIG_LEDS_GPIO=y
> CONFIG_LEDS_TRIGGERS=y
> CONFIG_LEDS_TRIGGER_TIMER=y
> CONFIG_LEDS_TRIGGER_ONESHOT=y
> CONFIG_LEDS_TRIGGER_HEARTBEAT=y
> CONFIG_LEDS_TRIGGER_GPIO=y
> CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
> CONFIG_LEDS_TRIGGER_TRANSIENT=y
>

Unfortunately I am still unable to reproduce the problem with leds-gpio.
I'm not observing any heavy usage with your test case:

~#free
              total       used       free     shared    buffers     cached
Mem:       1028092      61364     966728          0       8416      22396
-/+ buffers/cache:      30552     997540
Swap:            0          0          0


Actually you didn't give any numbers. What kernel version are you using?

-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2016-09-16 11:25 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 ` [ISSUE] Memleak in LED sysfs on heavy usage Daniel Gorsulowski
2016-09-13  7:16   ` Jacek Anaszewski
2016-09-16  7:31   ` Jacek Anaszewski
2016-09-16  8:15     ` Daniel Gorsulowski
2016-09-16 11:25       ` Jacek Anaszewski [this message]
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=4d51014d-c8fa-4687-cae8-1a8dd0f79beb@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=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.