Re: [RFC] de-asmify the x86-64 system call slowpath
From: Linus Torvalds
Date: Wed Feb 05 2014 - 21:33:10 EST
On Wed, Feb 5, 2014 at 4:55 PM, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> wrote:
>
> One thing that could help is THP for file-backed pages. And there's
> prototype with basic infrasturure and support for ramfs and
> shmem/tmpfs (by Ning Qu). Work in progress.
THP isn't really realistic for any general-purpose loads. 2MB pages
are just too big of a granularity.
On a machine with just a few gigs (ie anything but big servers), you
count the number of large pages in a few thousands. That makes
fragmentation a big issue. Also, ELF sections aren't actually
2MB-aligned, nor do you really want to throw away 9 bits of virtual
address space randomization. Plus common binaries aren't even big
enough. Look at "bash", which is a pig - it's still less than a
megabyte as just the binary, with the code segment being 900kB or so
for me. For something like "perl", it's even smaller, with a number of
shared object files that get loaded dynamically etc.
IOW, THP is completely useless for any kind of scripting. It can be
good for individual large binaries that have long lifetimes (DB
processes, HPC, stuff like that), but no, it is *not* the answer to
complex loads. And almost certainly never will be.
It's possible that some special case (glibc for example) could be
reasonably hacked to use a THP code segment, but that sounds unlikely.
And the virtual address randomization really gets hurt.
No, I was thinking "try to optimistically map 8 adjacent aligned pages
at a time" - that would be the same cacheline in the page tables, so
it would be fairly cheap if we couple it with a gang-lookup of the
pages in the page cache (or, for anonymous pages, by just
optimistically trying to do an order-3 page allocation, and if that
works, just map the 32kB allocation you got as eight individual
pages).
I know it's been discussed at some point, and I even have a dim memory
of having seen some really ugly patches.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/