On Wed, Jan 17, 2018 at 05:48:57PM +0800, Xishi Qiu wrote:
> > Did you notice an actual issue, or is this just theoretical concern.
>
> Yes, we have this problem on our production line.
> I find the page table memory takes 200-300M.
200MB? That's mapping 800GB of virtual address space. That mus
On 01/17/2018 10:48 AM, Xishi Qiu wrote:
> On 2018/1/17 17:16, Vlastimil Babka wrote:
>
>> On 12/29/2017 09:58 AM, Xishi Qiu wrote:
>>> When calling vfree(), it calls unmap_vmap_area() to clear page table,
>>> but do not free the memory of page table, why? just for performance?
>>
>> I guess it's
On 2018/1/17 17:16, Vlastimil Babka wrote:
> On 12/29/2017 09:58 AM, Xishi Qiu wrote:
>> When calling vfree(), it calls unmap_vmap_area() to clear page table,
>> but do not free the memory of page table, why? just for performance?
>
> I guess it's expected that the free virtual range and associat
On 12/29/2017 09:58 AM, Xishi Qiu wrote:
> When calling vfree(), it calls unmap_vmap_area() to clear page table,
> but do not free the memory of page table, why? just for performance?
I guess it's expected that the free virtual range and associated page
tables it might be reused later.
> If a dri
On 2017/12/29 16:58, Xishi Qiu wrote:
> When calling vfree(), it calls unmap_vmap_area() to clear page table,
> but do not free the memory of page table, why? just for performance?
>
> If a driver use vmalloc() and vfree() frequently, we will lost much
> page table memory, maybe oom later.
>
> T
When calling vfree(), it calls unmap_vmap_area() to clear page table,
but do not free the memory of page table, why? just for performance?
If a driver use vmalloc() and vfree() frequently, we will lost much
page table memory, maybe oom later.
Thanks,
Xishi Qiu
6 matches
Mail list logo
