From: Laura Abbott <lauraa@codeaurora.org>
To: Dave Hansen <dave@sr71.net>,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org
Cc: Neeti Desai <neetid@codeaurora.org>
Subject: Re: [RFC PATCH 3/4] mm/vmalloc.c: Allow lowmem to be tracked in vmalloc
Date: Thu, 14 Nov 2013 20:52:38 -0800 [thread overview]
Message-ID: <5285A896.3030204@codeaurora.org> (raw)
In-Reply-To: <52850C37.1080506@sr71.net>
On 11/14/2013 9:45 AM, Dave Hansen wrote:
> On 11/11/2013 03:26 PM, Laura Abbott wrote:
>> +config ENABLE_VMALLOC_SAVING
>> + bool "Intermix lowmem and vmalloc virtual space"
>> + depends on ARCH_TRACKS_VMALLOC
>> + help
>> + Some memory layouts on embedded systems steal large amounts
>> + of lowmem physical memory for purposes outside of the kernel.
>> + Rather than waste the physical and virtual space, allow the
>> + kernel to use the virtual space as vmalloc space.
>
> I really don't think this needs to be exposed with help text and so
> forth. How about just defining a 'def_bool n' with some comments and
> let the architecture 'select' it?
>
>> +#ifdef ENABLE_VMALLOC_SAVING
>> +int is_vmalloc_addr(const void *x)
>> +{
>> + struct rb_node *n;
>> + struct vmap_area *va;
>> + int ret = 0;
>> +
>> + spin_lock(&vmap_area_lock);
>> +
>> + for (n = rb_first(vmap_area_root); n; rb_next(n)) {
>> + va = rb_entry(n, struct vmap_area, rb_node);
>> + if (x >= va->va_start && x < va->va_end) {
>> + ret = 1;
>> + break;
>> + }
>> + }
>> +
>> + spin_unlock(&vmap_area_lock);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(is_vmalloc_addr);
>> +#endif
>
> It's probably worth noting that this makes is_vmalloc_addr() a *LOT*
> more expensive than it was before. There are a couple dozen of these in
> the tree in kinda weird places (ext4, netlink, tcp). You didn't
> mention it here, but you probably want to at least make sure you're not
> adding a spinlock and a tree walk in some critical path.
>
Yes, that was a concern I had as well. If is_vmalloc_addr returned true
the spinlock/tree walk would happen anyway so essentially this is
getting rid of the fast path. This is typically used in the idiom
alloc(size) {
if (size > some metric)
vmalloc
else
kmalloc
}
free (ptr) {
if (is_vmalloc_addr(ptr)
vfree
else
kfree
}
so my hypothesis would be that any path would have to be willing to take
the penalty of vmalloc anyway. The actual cost would depend on the
vmalloc / kmalloc ratio. I haven't had a chance to get profiling data
yet to see the performance difference.
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 4:52 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 [this message]
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
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=5285A896.3030204@codeaurora.org \
--to=lauraa@codeaurora.org \
--cc=dave@sr71.net \
--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).