Hi  

I see,
Is it possible to change this part:
https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/sound/soc/soc-core.c?h=master#n3772


so that it use vmalloc if it need allocate large memory for
struct snd_soc_pcm_runtime ?

Thanks 

-----Original Message-----
From: Lars-Peter Clausen [mailto:l...@metafoo.de] 
Sent: Monday, March 03, 2014 10:23 PM
To: Wang, Yalin
Cc: 'Takashi Iwai'; 'alsa-de...@alsa-project.org'; Mark Brown; 
'linux-kernel@vger.kernel.org'; Liam Girdwood
Subject: Re: [alsa-devel] change kmalloc into vmalloc for large memory 
allocations

On 03/03/2014 02:29 PM, Wang, Yalin wrote:
> Hi
>
>
> I find the num_links are defined here:
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/sound/soc
> /msm/msm8226.c?h=msm-3.10&id=d681c8e79c597a5e1ae79803dc0215d02df8fe34#
> n1812
>
>
> the ARRAY_SIZE is 42 , you mean the driver can't define so many elements ?
> how to implement it if we can't do like this ?
>

Looks like your platform is a bit special in this regard and requires quite a 
few more links than usual.

> Thanks
>
> -----Original Message-----
> From: Lars-Peter Clausen [mailto:l...@metafoo.de]
> Sent: Monday, March 03, 2014 7:46 PM
> To: Wang, Yalin
> Cc: 'Takashi Iwai'; 'alsa-de...@alsa-project.org'; Mark Brown; 
> 'linux-kernel@vger.kernel.org'; Liam Girdwood
> Subject: Re: [alsa-devel] change kmalloc into vmalloc for large memory 
> allocations
>
> On 03/03/2014 12:36 PM, Wang, Yalin wrote:
>> Hi
>>
>> I am curious what number range is correct here for card->num_links ?
>
> It depends on your board. But typically I'd say <= 5, for most boards it's 
> either 1 or 2.
>
>>
>>
>> Thanks
>>
>> -----Original Message-----
>> From: Lars-Peter Clausen [mailto:l...@metafoo.de]
>> Sent: Monday, March 03, 2014 7:35 PM
>> To: Wang, Yalin
>> Cc: 'Takashi Iwai'; 'alsa-de...@alsa-project.org'; Mark Brown; 
>> 'linux-kernel@vger.kernel.org'; Liam Girdwood
>> Subject: Re: [alsa-devel] change kmalloc into vmalloc for large 
>> memory allocations
>>
>> On 03/03/2014 12:13 PM, Wang, Yalin wrote:
>>> Hi
>>>
>>>
>>> I add logs in kernel , the result is :
>>>
>>> 532 <4>[    5.690094] @@ sizeof(struct snd_soc_pcm_runtime)=1488 
>>> card->num_links=42 card->num_aux_devs=0
>>>
>>> card->num_links=42 , is it correct ?
>>
>> Very unlikely. Make sure that it is properly initialized in your machine 
>> driver.
>>
>>>
>>> our hardware is qcom msm8x26 platform .
>>
>> This one doesn't seem to be in upstream.
>>
>>>
>>> Thanks
>>>
>>> -----Original Message-----
>>> From: Takashi Iwai [mailto:ti...@suse.de]
>>> Sent: Monday, March 03, 2014 5:23 PM
>>> To: Wang, Yalin
>>> Cc: 'linux-kernel@vger.kernel.org'; Mark Brown; 'pe...@perex.cz'; 
>>> 'alsa-de...@alsa-project.org'; Liam Girdwood
>>> Subject: Re: change kmalloc into vmalloc for large memory 
>>> allocations
>>>
>>> At Mon, 03 Mar 2014 10:19:58 +0100,
>>> Takashi Iwai wrote:
>>>>
>>>> [Dropped unrelated subsystem MLs, and corrected Liam's address]
>>>
>>> Grrr, even Mark's address was obsoleted.  Here corrected.
>>>
>>>
>>> Takashi
>>>
>>>>
>>>> At Mon, 3 Mar 2014 09:55:15 +0800,
>>>> Wang, Yalin wrote:
>>>>>
>>>>> Hi  Takashi,
>>>>>
>>>>> For this one:
>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/s
>>>>> o
>>>>> u
>>>>> nd/soc/soc-core.c?h=master#n3772
>>>>>
>>>>> in my kernel log,
>>>>> the allocation size 62496,
>>>>> about 62KB,
>>>>
>>>> This looks way too much than expected.  I thought each struct 
>>>> snd_soc_pcm_runtime should be 1 or 2kB.  The code allocating an 
>>>> arary of snd_soc_pcm_runtime, so this might be due to some invalid 
>>>> values there.
>>>>
>>>>> I think need to  change to vmalloc .
>>>>> How do you think of it ?
>>>>
>>>> This looks rather like a bug somewhere around it.
>>>>
>>>> Could you check the values there, sizeof(struct 
>>>> snd_soc_pcm_runtime),
>>>> card->num_links and card->num_aux_devs?
>>>>
>>>> And, with which hardware is the issue examined?
>>>>
>>>>
>>>> thanks,
>>>>
>>>> Takashi
>>>>
>>>>>
>>>>> Logs:
>>>>> <4>[   11.469789] ------------[ cut here ]------------
>>>>> <4>[   11.469803] WARNING: at 
>>>>> /media/00DE7FE2DE7FCE82/jb-mr2-yukon/kernel/include/linux/slub_def.h:265 
>>>>> __kmalloc+0x38/0x29c()
>>>>> <4>[   11.469811] size=62496 flags=80d0
>>>>> <4>[   11.469815] Modules linked in:
>>>>> <4>[   11.469835] [<c010c534>] (unwind_backtrace+0x0/0x11c) from 
>>>>> [<c018ab04>] (warn_slowpath_common+0x4c/0x64)
>>>>> <4>[   11.469850] [<c018ab04>] (warn_slowpath_common+0x4c/0x64) from 
>>>>> [<c018ab9c>] (warn_slowpath_fmt+0x2c/0x3c)
>>>>> <4>[   11.469864] [<c018ab9c>] (warn_slowpath_fmt+0x2c/0x3c) from 
>>>>> [<c0249ab4>] (__kmalloc+0x38/0x29c)
>>>>> <4>[   11.469879] [<c0249ab4>] (__kmalloc+0x38/0x29c) from [<c06a0124>] 
>>>>> (snd_soc_register_card+0x184/0x104c)
>>>>> <4>[   11.469896] [<c06a0124>] (snd_soc_register_card+0x184/0x104c) from 
>>>>> [<c088183c>] (msm8226_asoc_machine_probe+0x298/0x7f0)
>>>>> <4>[   11.469913] [<c088183c>] (msm8226_asoc_machine_probe+0x298/0x7f0) 
>>>>> from [<c044b1fc>] (platform_drv_probe+0x14/0x18)
>>>>> <4>[   11.469927] [<c044b1fc>] (platform_drv_probe+0x14/0x18) from 
>>>>> [<c0449f2c>] (driver_probe_device+0x134/0x334)
>>>>> <4>[   11.469940] [<c0449f2c>] (driver_probe_device+0x134/0x334) from 
>>>>> [<c044a194>] (__driver_attach+0x68/0x8c)
>>>>> <4>[   11.469953] [<c044a194>] (__driver_attach+0x68/0x8c) from 
>>>>> [<c044849c>] (bus_for_each_dev+0x48/0x80)
>>>>> <4>[   11.469965] [<c044849c>] (bus_for_each_dev+0x48/0x80) from 
>>>>> [<c0449528>] (bus_add_driver+0x100/0x26c)
>>>>> <4>[   11.469978] [<c0449528>] (bus_add_driver+0x100/0x26c) from 
>>>>> [<c044a66c>] (driver_register+0x9c/0x120)
>>>>> <4>[   11.469992] [<c044a66c>] (driver_register+0x9c/0x120) from 
>>>>> [<c010052c>] (do_one_initcall+0x90/0x160)
>>>>> <4>[   11.470007] [<c010052c>] (do_one_initcall+0x90/0x160) from 
>>>>> [<c0d00b74>] (kernel_init+0xec/0x1a8)
>>>>> <4>[   11.470022] [<c0d00b74>] (kernel_init+0xec/0x1a8) from [<c0106aec>] 
>>>>> (kernel_thread_exit+0x0/0x8)
>>>>> <4>[   11.470030] ---[ end trace 1b75b31a2719ed4d ]---
>>>>>
>>>>> BRs/ Yalin
>>>>> -----Original Message-----
>>>>> From: Takashi Iwai [mailto:ti...@suse.de]
>>>>> Sent: Friday, February 28, 2014 10:20 PM
>>>>> To: Wang, Yalin
>>>>> Cc: 'linux-kernel@vger.kernel.org'; 'linux-arm-...@vger.kernel.org'; 
>>>>> 'linux-arm-ker...@lists.infradead.org'; 'linux-in...@vger.kernel.org'; 
>>>>> 'ba...@ti.com'; 'gre...@linuxfoundation.org'; 'l...@ti.com'; 
>>>>> 'broo...@opensource.wolfsonmicro.com'; 'pe...@perex.cz'; 
>>>>> 'pa...@netfilter.org'; 'ka...@trash.net'; 'da...@davemloft.net'; 
>>>>> 'rost...@goodmis.org'; 'fweis...@gmail.com'; 'mi...@redhat.com'; 
>>>>> 'dmitry.torok...@gmail.com'; 'rydb...@euromail.se'; 
>>>>> 'linux-...@vger.kernel.org'; 'alsa-de...@alsa-project.org'; 
>>>>> 'netfilter-de...@vger.kernel.org'; 'netfil...@vger.kernel.org'; 
>>>>> 'coret...@netfilter.org'; 'net...@vger.kernel.org'
>>>>> Subject: Re: change kmalloc into vmalloc for large memory 
>>>>> allocations
>>>>>
>>>>> At Fri, 28 Feb 2014 16:15:23 +0800, Wang, Yalin wrote:
>>>>>>
>>>>>> Hi
>>>>>>
>>>>>>
>>>>>> I find there is some drivers use kmalloc to allocate large 
>>>>>> Memorys during module_init,  some can be changed to use vmalloc 
>>>>>> To save some low mem, I add log in kernel to track , And list them here:
>>>>>>
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/
>>>>>> d
>>>>>> rive
>>>>>> rs/usb/gadget/f_mass_storage.c?h=master#n2724
>>>>>>
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/
>>>>>> s
>>>>>> ound
>>>>>> /soc/soc-core.c?h=master#n3772
>>>>>
>>>>> At least the ASoC runtime case doesn't use the allocated memory as 
>>>>> buffer, and they are allocated only once per device, thus it shouldn't be 
>>>>> the problem you stated.  If it really consumes so much memory, we need to 
>>>>> rethink, instead of allocating an array but allocate each object, for 
>>>>> example.
>>>>>
>>>>>
>>>>> thanks,
>>>>>
>>>>> Takashi
>>>>>
>>>>>
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/
>>>>>> n
>>>>>> et/n
>>>>>> etfilter/nf_conntrack_ftp.c?h=master#n603
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/
>>>>>> n
>>>>>> et/n
>>>>>> etfilter/nf_conntrack_h323_main.c?h=master#n1849
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/
>>>>>> n
>>>>>> et/n
>>>>>> etfilter/nf_conntrack_irc.c?h=master#n247
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/
>>>>>> n
>>>>>> et/n
>>>>>> etfilter/nf_conntrack_sane.c?h=master#n195
>>>>>>
>>>>>> https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/tree/
>>>>>> d
>>>>>> rive
>>>>>> rs/input/evdev.c?h=master#n403
>>>>>>
>>>>>>
>>>>>> they allocate large memory from 10k~64K , this will use lots of 
>>>>>> low mem, instead if we use vmalloc for these drivers , it will be 
>>>>>> good for some devices like smart phone, we often encounter some 
>>>>>> errors like kmalloc failed because there is not enough low mem , 
>>>>>> especially when the device has physical memory less than 1GB .
>>>>>>
>>>>>>
>>>>>> could this module change the memory allocation into vmalloc ?
>>>>>>
>>>>>> I was thinking that if we can introduce a helper function in kmalloc.h 
>>>>>> like this :
>>>>>>
>>>>>> Kmalloc(size, flags)
>>>>>> {
>>>>>>  If (size > PAGE_SIZE && flags&CAN_USE_VMALLOC_FLAG)
>>>>>>          return vmalloc(size);
>>>>>>  Else
>>>>>>          return real_kmalloc(size);
>>>>>> }
>>>>>>
>>>>>> Kfree(ptr)
>>>>>> {
>>>>>>  If (is_vmalloc_addr(ptr))
>>>>>>          Vfree(ptr);
>>>>>>  Else
>>>>>>          Kfree(ptr);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> But we need add some flags to ensure always use kmalloc for Some 
>>>>>> special use (dma etc..)
>>>>>>
>>>>>> How do you think of it ?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> alsa-de...@alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to