From: Laura Abbott <lauraa@codeaurora.org>
To: Dave Hansen <dave.hansen@intel.com>,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Cc: Neeti Desai <neetid@codeaurora.org>
Subject: Re: [RFC PATCH 4/4] mm/vmalloc.c: Treat the entire kernel virtual space as vmalloc
Date: Thu, 14 Nov 2013 21:34:14 -0800 [thread overview]
Message-ID: <5285B256.6050403@codeaurora.org> (raw)
In-Reply-To: <528507BA.9010101@intel.com>
On 11/14/2013 9:26 AM, Dave Hansen wrote:
> On 11/11/2013 03:26 PM, Laura Abbott wrote:
>> With CONFIG_ENABLE_VMALLOC_SAVINGS, all lowmem is tracked in
>> vmalloc. This means that all the kernel virtual address space
>> can be treated as part of the vmalloc region. Allow vm areas
>> to be allocated from the full kernel address range.
>>
>> Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
>> Signed-off-by: Neeti Desai <neetid@codeaurora.org>
>> ---
>> mm/vmalloc.c | 11 +++++++++++
>> 1 files changed, 11 insertions(+), 0 deletions(-)
>>
>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> index c7b138b..181247d 100644
>> --- a/mm/vmalloc.c
>> +++ b/mm/vmalloc.c
>> @@ -1385,16 +1385,27 @@ struct vm_struct *__get_vm_area_caller(unsigned long size, unsigned long flags,
>> */
>> struct vm_struct *get_vm_area(unsigned long size, unsigned long flags)
>> {
>> +#ifdef CONFIG_ENABLE_VMALLOC_SAVING
>> + return __get_vm_area_node(size, 1, flags, PAGE_OFFSET, VMALLOC_END,
>> + NUMA_NO_NODE, GFP_KERNEL,
>> + __builtin_return_address(0));
>> +#else
>> return __get_vm_area_node(size, 1, flags, VMALLOC_START, VMALLOC_END,
>> NUMA_NO_NODE, GFP_KERNEL,
>> __builtin_return_address(0));
>> +#endif
>> }
>>
>> struct vm_struct *get_vm_area_caller(unsigned long size, unsigned long flags,
>> const void *caller)
>> {
>> +#ifdef CONFIG_ENABLE_VMALLOC_SAVING
>> + return __get_vm_area_node(size, 1, flags, PAGE_OFFSET, VMALLOC_END,
>> + NUMA_NO_NODE, GFP_KERNEL, caller);
>> +#else
>> return __get_vm_area_node(size, 1, flags, VMALLOC_START, VMALLOC_END,
>> NUMA_NO_NODE, GFP_KERNEL, caller);
>> +#endif
>> }
>
> Couple of nits: first of all, there's no reason to copy, paste, and
> #ifdef this much code. This just invites one of the copies to bitrot.
> I'd much rather see this:
>
> #ifdef CONFIG_ENABLE_VMALLOC_SAVING
> #define LOWEST_VMALLOC_VADDR PAGE_OFFSET
> #else
> #define LOWEST_VMALLOC_VADDR VMALLOC_START
> #endif
>
> Then just replace the PAGE_OFFSET in the function arguments with
> LOWEST_VMALLOC_VADDR.
>
Good point.
> Have you done any audits to make sure that the rest of the code that
> deals with vmalloc addresses in the kernel is using is_vmalloc_addr()?
> I'd be a bit worried that we might have picked up an assumption or two
> that *all* vmalloc addresses are _above_ VMALLOC_START.
>
> The percpu.c code looks like it might do this, and maybe the kcore code.
> The vmalloc.c code itself has this in get_vmalloc_info():
>
>> /*
>> * Some archs keep another range for modules in vmalloc space
>> */
>> if (addr < VMALLOC_START)
>> continue;
>
> Seems like that would break as well.
>
> With this patch, VMALLOC_START loses enough of its meaning that I wonder
> if we should even keep it around. It's the start of the _dedicated_
> vmalloc space, but it's mostly useless and obscure enough that maybe we
> should get rid of its use in common code.
>
Yes, there are plenty of clients who are using VMALLOC_START. There
might still be a use for VMALLOC_START as marking 'no more direct mapped
memory above this address' . To start making some if the cleanup easier,
it would help to have an already calculated total amount of vmalloc for
the clients who are trying to work off a vmalloc percentage.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-11-15 5:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 23:26 [RFC 0/4] Intermix Lowmem and vmalloc Laura Abbott
2013-11-11 23:26 ` [RFC PATCH 1/4] arm: mm: Add iotable_init_novmreserve Laura Abbott
2013-11-11 23:26 ` [RFC PATCH 2/4] arm: mm: Track lowmem in vmalloc Laura Abbott
2013-11-11 23:26 ` [RFC PATCH 3/4] mm/vmalloc.c: Allow lowmem to be tracked " Laura Abbott
2013-11-11 23:37 ` Kyungmin Park
2013-11-12 1:23 ` Laura Abbott
2013-11-14 17:45 ` Dave Hansen
2013-11-15 4:52 ` Laura Abbott
2013-11-15 15:53 ` Dave Hansen
2013-11-26 22:45 ` Andrew Morton
2013-12-03 4:59 ` Laura Abbott
2013-11-11 23:26 ` [RFC PATCH 4/4] mm/vmalloc.c: Treat the entire kernel virtual space as vmalloc Laura Abbott
2013-11-14 17:26 ` Dave Hansen
2013-11-15 5:34 ` Laura Abbott [this message]
2013-11-12 0:13 ` [RFC 0/4] Intermix Lowmem and vmalloc Russell King - ARM Linux
2013-11-12 1:24 ` Laura Abbott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5285B256.6050403@codeaurora.org \
--to=lauraa@codeaurora.org \
--cc=dave.hansen@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=neetid@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).