From: Alexey Dobriyan <adobriyan@gmail.com>
To: hpa@zytor.com
Cc: Ingo Molnar <mingo@kernel.org>,
tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [PATCH] x86_64: uninline TASK_SIZE
Date: Mon, 22 Apr 2019 00:10:07 +0300 [thread overview]
Message-ID: <20190421211007.GA30444@avx2> (raw)
In-Reply-To: <8B42CD57-9343-4234-A96D-80337BFFDF0E@zytor.com>
On Sun, Apr 21, 2019 at 01:07:08PM -0700, hpa@zytor.com wrote:
> On April 21, 2019 11:28:42 AM PDT, Ingo Molnar <mingo@kernel.org> wrote:
> >
> >* Alexey Dobriyan <adobriyan@gmail.com> wrote:
> >
> >> TASK_SIZE macro is quite deceptive: it looks like a constant but in
> >fact
> >> compiles to 50+ bytes.
> >>
> >> Space savings on x86_64 defconfig:
> >>
> >> add/remove: 1/0 grow/shrink: 3/24 up/down: 77/-2247 (-2170)
> >> Function old new delta
> >> _task_size - 52 +52
> >> mpol_shared_policy_init 344 363 +19
> >> shmem_get_unmapped_area 92 97 +5
> >> __rseq_handle_notify_resume.cold 34 35 +1
> >> copy_from_user_nmi 123 113 -10
> >> mmap_address_hint_valid 92 56 -36
> >> arch_get_unmapped_area_topdown 471 435 -36
> >> tlb_gather_mmu 164 126 -38
> >> hugetlb_get_unmapped_area 774 736 -38
> >> __create_xol_area 497 458 -39
> >> arch_tlb_gather_mmu 160 120 -40
> >> setup_new_exec 380 336 -44
> >> __x64_sys_mlockall 378 333 -45
> >> __ia32_sys_mlockall 378 333 -45
> >> tlb_flush_mmu 235 189 -46
> >> unmap_page_range 2098 2048 -50
> >> copy_mount_options 518 465 -53
> >> __get_user_pages 1737 1675 -62
> >> get_unmapped_area 270 204 -66
> >> perf_prepare_sample 1176 1098 -78
> >> perf_callchain_user 549 469 -80
> >> mremap_to.isra 545 457 -88
> >> arch_tlb_finish_mmu 394 305 -89
> >> __do_munmap 1039 927 -112
> >> elf_map 527 409 -118
> >> prctl_set_mm 1509 1335 -174
> >> __rseq_handle_notify_resume 1116 906 -210
> >> load_elf_binary 11761 11111 -650
> >> Total: Before=14121337, After=14119167, chg -0.02%
> >>
> >> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >> ---
> >>
> >> arch/x86/include/asm/processor.h | 4 ++--
> >> arch/x86/kernel/Makefile | 1 +
> >> arch/x86/kernel/task_size_64.c | 9 +++++++++
> >> 3 files changed, 12 insertions(+), 2 deletions(-)
> >>
> >> --- a/arch/x86/include/asm/processor.h
> >> +++ b/arch/x86/include/asm/processor.h
> >> @@ -887,8 +887,8 @@ static inline void spin_lock_prefetch(const void
> >*x)
> >>
> >> #define TASK_SIZE_LOW (test_thread_flag(TIF_ADDR32) ? \
> >> IA32_PAGE_OFFSET : DEFAULT_MAP_WINDOW)
> >> -#define TASK_SIZE (test_thread_flag(TIF_ADDR32) ? \
> >> - IA32_PAGE_OFFSET : TASK_SIZE_MAX)
> >> +unsigned long _task_size(void);
> >> +#define TASK_SIZE _task_size()
> >> #define TASK_SIZE_OF(child) ((test_tsk_thread_flag(child,
> >TIF_ADDR32)) ? \
> >> IA32_PAGE_OFFSET : TASK_SIZE_MAX)
> >>
> >> --- a/arch/x86/kernel/Makefile
> >> +++ b/arch/x86/kernel/Makefile
> >> @@ -46,6 +46,7 @@ CFLAGS_irq.o := -I$(src)/../include/asm/trace
> >>
> >> obj-y := process_$(BITS).o signal.o
> >> obj-$(CONFIG_COMPAT) += signal_compat.o
> >> +obj-$(CONFIG_X86_64) += task_size_64.o
> >> obj-y += traps.o idt.o irq.o irq_$(BITS).o dumpstack_$(BITS).o
> >> obj-y += time.o ioport.o dumpstack.o nmi.o
> >> obj-$(CONFIG_MODIFY_LDT_SYSCALL) += ldt.o
> >> new file mode 100644
> >> --- /dev/null
> >> +++ b/arch/x86/kernel/task_size_64.c
> >> @@ -0,0 +1,9 @@
> >> +#include <linux/export.h>
> >> +#include <linux/sched.h>
> >> +#include <linux/thread_info.h>
> >> +
> >> +unsigned long _task_size(void)
> >> +{
> >> + return test_thread_flag(TIF_ADDR32) ? IA32_PAGE_OFFSET :
> >TASK_SIZE_MAX;
> >> +}
> >> +EXPORT_SYMBOL(_task_size);
> >
> >Good idea - but instead of adding yet another compilation unit, why not
> >
> >stick _task_size() into arch/x86/kernel/process_64.c, which is the
> >canonical place for process management related arch functions?
> >
> >Thanks,
> >
> > Ingo
>
> Better yet... since TIF_ADDR32 isn't something that changes randomly, perhaps this should be a separate variable?
Maybe. I only thought about putting every 32-bit related flag under
CONFIG_COMPAT to further eradicate bloat (and force everyone else
to keep an eye on it, ha-ha).
next prev parent reply other threads:[~2019-04-21 21:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-21 16:06 [PATCH] x86_64: uninline TASK_SIZE Alexey Dobriyan
2019-04-21 18:28 ` Ingo Molnar
2019-04-21 20:07 ` hpa
2019-04-21 21:10 ` Alexey Dobriyan [this message]
2019-04-22 10:34 ` Ingo Molnar
2019-04-22 14:30 ` Andy Lutomirski
2019-04-22 22:09 ` Alexey Dobriyan
2019-04-23 0:54 ` Andy Lutomirski
2019-04-23 11:12 ` Ingo Molnar
2019-04-23 17:21 ` Andy Lutomirski
2019-04-24 10:38 ` Ingo Molnar
2019-04-22 22:04 ` Alexey Dobriyan
2019-04-21 22:07 ` [PATCH v2] " Alexey Dobriyan
2019-04-22 22:40 ` [PATCH] " Linus Torvalds
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=20190421211007.GA30444@avx2 \
--to=adobriyan@gmail.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.