Re: [benchmark] 1% performance overhead of paravirt_ops on native kernels

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 9 Jun 2009, Nick Piggin wrote:
> > 
> > And don't get me wrong - I don't like HIGHMEM. I detest the damn thing. I 
> > hated having to merge it, and I still hate it. It's a stupid, ugly, and 
> > very invasive config option. It's just that it's there to support a 
> > stupid, ugly and very annoying fundamental hardware problem.
> 
> I was looking forward to be able to get rid of it... unfortunately
> other 32-bit architectures are starting to use it again :(

.. and 32-bit x86 is still not dead, and there are still people who use it 
with more than 1G of RAM (ie it's not like it's just purely a "small 
embedded cell-phones with Atom" kind of thing that Intel seems to be 
pushing for eventually).

> I guess it is not incredibly intrusive for generic mm code. A bit
> of kmap sprinkled around which is actually quite a useful delimiter
> of where pagecache is addressed via its kernel mapping.
> 
> Do you hate more the x86 code? Maybe that can be removed?

No, we can't remove the x86 code, and quite frankly, I don't even mind 
that. The part I mind is actually the sprinkling of kmap all over. Do a 
"git grep kmap fs", and you'll see that there are four times as many 
kmap's in filesystem code than there are in mm/.

I was benchmarking btrfs on my little EeePC. There, kmap overhead was 25% 
of file access time. Part of it is that people have been taught to use 
"kmap_atomic()", which is usable under spinlocks and people have been told 
that it's "fast". It's not fast. The whole TLB thing is slow as hell. 

Oh well. It's sad. But we can't get rid of it.

			Linus