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

[Nick Piggin]

On Tue, Jun 09, 2009 at 07:54:00AM -0700, Linus Torvalds wrote:
> 
> 
> 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/.

Yeah, I guess I just don't see it as such a bad thing. As I said,
it's nice to have something to grep for and not have pointers into
pagecache stored around the place (although filesystems do that
with buffercache).

If code has to jump through particular nasty hoops to use atomic
kmaps, that's not such a good thing...


> 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.

If it's such a problem, it could be made a lot faster without too
much problem. You could just introduce a FIFO of ptes behind it 
and flush them all in one go. 4K worth of ptes per CPU might
hopefully bring your overhead down to < 1%.


--
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/