request_firmware API exhaust memory
in [Kernel]
|
Prev: uml: i386: Avoid redefinition of NR_syscalls
Next: rcu: slim down rcutiny by removing rcu_scheduler_active and friends
From: Tomas Winkler on 19 Apr 2010 08:30 Lately we've been developing a device that rather more extensively used request_firmware API in load and also using pm_notifiers to load firmware. In some stress testing the usage will exhaust the system memory. First we suspected there is a memory leak in the firwmare_class but eventually what is that udevd piles up it takes time to collect the process. We loose ~ 500K for each request/release_firmware iteration. After the stress the process table will will look something like shown below, If someone with more insight can point out what part of this firmware load has to be fixed and what is the best strategy request_firmware API used extensively. I believe currently only Orinoco driver uses pm_notifies to load firmware before S3/S4 but if there are more drivers like that it might actually create a real problem during suspend on some small systems. root 514 0.0 0.0 15480 1116 ? S<s Apr01 0:01 /sbin/udevd -d root 28989 0.0 0.0 15476 968 ? S< 14:07 0:00 /sbin/udevd -d root 28995 0.0 0.0 15476 976 ? S< 14:07 0:00 /sbin/udevd -d root 31616 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31622 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31627 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31633 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31638 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31644 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31649 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31655 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31660 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31666 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31671 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31677 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31682 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31688 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31693 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31699 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31704 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31710 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31715 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31721 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31726 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31732 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31737 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31743 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31748 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31754 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31759 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31765 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31770 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31776 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31781 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31787 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31792 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31798 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31803 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31809 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31814 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31820 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31825 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31831 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31836 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31842 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d root 31847 0.0 0.0 15476 916 ? S< 14:49 0:00 /sbin/udevd -d root 31853 0.0 0.0 15476 888 ? S< 14:49 0:00 /sbin/udevd -d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kay Sievers on 19 Apr 2010 08:40 On Mon, Apr 19, 2010 at 14:20, Tomas Winkler <tomasw(a)gmail.com> wrote: > Lately we've been developing a device that rather more extensively > used request_firmware API in load and also using pm_notifiers to load > firmware. In some stress testing the usage will exhaust the system > memory. First we suspected there is a memory leak in the > firwmare_class but eventually what is that udevd piles up it takes > time to collect the process. What version of the kernel, and what version of udev? > We loose ~ 500K for each > request/release_firmware iteration. You mean you lose 500k, not taken by any process? > After the stress the process table will will look something like shown below, What are these processes doing (strace)? Do they have child processes? If yes, what are they doing (strace)? Kay -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Greg KH on 19 Apr 2010 11:00 On Mon, Apr 19, 2010 at 03:20:34PM +0300, Tomas Winkler wrote: > Lately we've been developing a device that rather more extensively > used request_firmware API in load and also using pm_notifiers to load > firmware. Do you have a pointer to your driver source anywhere that shows how you are trying to use the firmware api in this manner? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tomas Winkler on 21 Apr 2010 18:30 On Mon, Apr 19, 2010 at 5:59 PM, Greg KH <greg(a)kroah.com> wrote: > On Mon, Apr 19, 2010 at 03:20:34PM +0300, Tomas Winkler wrote: >> Lately we've been developing a device that rather more extensively >> used request_firmware API in load and also using pm_notifiers to load >> firmware. > > Do you have a pointer to your driver source anywhere that shows how you > are trying to use the firmware api in this manner? I've attached a very simple test driver I'm using. Just wanted to eliminate anything else. Bellow is a little script that loads and releases the firmware. My previous observation was wrong. The free memory gradually decreases regardless of number or dangling udevd forks, which are eventually collected if the sleep period is long enough ~10s. testfw=${1:-test-fw600k.fw} count=${2:-100} s=${3:-10} for ((i=0; i<$count ; i++)) ; do echo -n $testfw > /sys/devices/platform/fw-test/load_fw echo -n 1 > /sys/devices/platform/fw-test/release_fw sleep $s grep MemFree /proc/meminfo | awk '{print $2}' ps auxwww | grep udevd | wc -l done Thanks Tomas
From: Greg KH on 25 Apr 2010 12:40
On Thu, Apr 22, 2010 at 01:22:51AM +0300, Tomas Winkler wrote: > On Mon, Apr 19, 2010 at 5:59 PM, Greg KH <greg(a)kroah.com> wrote: > > On Mon, Apr 19, 2010 at 03:20:34PM +0300, Tomas Winkler wrote: > >> Lately we've been developing a device that rather more extensively > >> used request_firmware API in load and also using pm_notifiers to load > >> firmware. > > > > Do you have a pointer to your driver source anywhere that shows how you > > are trying to use the firmware api in this manner? > > I've attached a very simple test driver I'm using. Just wanted to > eliminate anything else. > Bellow is a little script that loads and releases the firmware. My > previous observation was wrong. > The free memory gradually decreases regardless of number or dangling > udevd forks, which are eventually collected if the sleep period is > long enough ~10s. That sounds normal for the free memory. Kay, that's also to be expected for the udevd forks as well, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |