On Mon, 29 Jun 2020, Matthew Wilcox wrote:
> Sounds like we need a test somewhere that checks this behaviour.
>
> > In order to make such allocations possible one would have to create yet
> > another kmalloc array for high memory.
>
> Not for this case because it goes straight to kmalloc_order().
On Mon, Jun 29, 2020 at 02:48:06PM +, Christopher Lameter wrote:
> On Sat, 27 Jun 2020, Long Li wrote:
> > Environment using the slub allocator, 1G memory in my ARM32.
> > kmalloc(1024, GFP_HIGHUSER) can allocate memory normally,
> > kmalloc(64*1024, GFP_HIGHUSER) will cause a memory leak,
On Mon, 29 Jun 2020, Matthew Wilcox wrote:
> Slab used to disallow GFP_HIGHMEM allocations earlier than this,
It is still not allowed and not supported.
On Sat, 27 Jun 2020, Long Li wrote:
> Environment using the slub allocator, 1G memory in my ARM32.
> kmalloc(1024, GFP_HIGHUSER) can allocate memory normally,
> kmalloc(64*1024, GFP_HIGHUSER) will cause a memory leak, because
> alloc_pages returns highmem physical pages, but it cannot be directly
On Sat, Jun 27, 2020 at 04:55:07AM +, Long Li wrote:
> Environment using the slub allocator, 1G memory in my ARM32.
> kmalloc(1024, GFP_HIGHUSER) can allocate memory normally,
> kmalloc(64*1024, GFP_HIGHUSER) will cause a memory leak, because
> alloc_pages returns highmem physical pages, but
Environment using the slub allocator, 1G memory in my ARM32.
kmalloc(1024, GFP_HIGHUSER) can allocate memory normally,
kmalloc(64*1024, GFP_HIGHUSER) will cause a memory leak, because
alloc_pages returns highmem physical pages, but it cannot be directly
converted into a virtual address and return
6 matches
Mail list logo
