UBI memory leak after creating and removing volumes

[John Smith]

Artem Bityutskiy wrote:
> On Tue, 2009-02-17 at 14:33 +0000, John.Smith at pace.com wrote:
>> After 0, 1000 and 2000 iterations of a test of creating 2 UBI volumes,
>> then removing them, /proc/slab_allocators shows these three items
>> obviously increasing:
>>
>> inode_cache: 327 alloc_inode+0x140/0x148         
>> inode_cache: 3329 alloc_inode+0x140/0x148        
>> inode_cache: 6329 alloc_inode+0x140/0x148        
>> (3 objects per iteration)
>>
>> sysfs_dir_cache: 1402 sysfs_new_dirent+0x2c/0xa0 
>> sysfs_dir_cache: 15402 sysfs_new_dirent+0x2c/0xa0
>> sysfs_dir_cache: 29402 sysfs_new_dirent+0x2c/0xa0
>> (14 objects per iteration)
>>
>> dentry_cache: 669 d_alloc+0x30/0x214             
>> dentry_cache: 3823 d_alloc+0x30/0x214            
>> dentry_cache: 6823 d_alloc+0x30/0x214            
>> (3 objects per iteration)
> 
> Hmm, may be this is related to sysfs? Every time you create or delete
> a volume UBIFS creates/deletes sysfs entries. May be some are forgotten,
> or it messes up kobject refcounting, so the kobjects are never released.
> 
I agree, they seem to be sysfs things.

>> I don't know how to track these things down fully. But I 
>> believe they relate to the elevator queue.
> 
> Hmm? Sorry, did not realize how elevator may be involved into
> UBI volume creation/deletion. You mean when we create a volume,
> userspace udev is called, and creates device node on your host
> FS, which involves elevators? You can try disabling udev then.
> 
I don't think udev is involved.

This is my understanding:
When an UBI volume is created, a matching MTD device is created.
The MTD device has both character and block device variants.
A block device is typically like a disk, so needs some sort of
queue and elevator algorithm to manage the accesses to the disk.
Typically there is one queue per disk. But in MTD world there
is no real need for a queue and cunning algorithm, so the is
just one queue for all the MTD devices, managed by a kernel thread.

In some sense the sysfs entries corresponding to the queue
should be linked to some toplevel MTD entity, and referenced
from the MTD block devices. Instead the queue seems to be present
in all the mtd block devices, and something doesn't quite work.

Thanks for your replies,

Regards,
John

John Smith

P.S. Please forgive the disclaimer which is probably about to
be appended automatically. I will try to get it removed.
This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. <http://www.pace.com>
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace's standard terms and conditions of sale which may have been provided to you, or in any event are available at http://www.pace.com/uktcsale.pdf (ii) all orders for goods and/or services placed by Pace are subject to Pace's standard terms and conditions of purchase which may have been provided to you, or in any event are available at http://www.pace.com/uktcpurch.pdf. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com