Re: CVS commit: src/sys/arch

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Wed, Jan 10, 2018 at 19:45:26 +0100, Maxime Villard wrote:

> Le 04/01/2018 ? 15:50, Valery Ushakov a ?crit :
> > On Thu, Jan 04, 2018 at 13:36:30 +0000, Maxime Villard wrote:
> > 
> > > Module Name:	src
> > > Committed By:	maxv
> > > Date:		Thu Jan  4 13:36:30 UTC 2018
> > > 
> > > Modified Files:
> > > 	src/sys/arch/amd64/amd64: genassym.cf locore.S machdep.c
> > > 	src/sys/arch/i386/i386: genassym.cf locore.S machdep.c
> > > 	src/sys/arch/x86/include: cpu.h
> > > 	src/sys/arch/x86/x86: intr.c pmap.c sys_machdep.c
> > > 
> > > Log Message:
> > > Allocate the TSS area dynamically. This way cpu_info and cpu_tss can be
> > > put in separate pages.
> > 
> > Splitting tss and cpu info speeds up NetBSD under virtualbox without
> > VT-x quite a bit as vbox traps all TSS accesses and so all the
> > same-page cpu_info accesses are also trapped, slowing things down.
> 
> Did you actually test? And if so, did my commit really change something?

I haven't tested this commit specifically, but I did test it with a
quick hack a few years ago

  https://mail-index.netbsd.org/netbsd-users/2013/06/21/msg013010.html

I don't remember the exact numbers, but it was a lot.  If memory
serves, compiling the kernel was 4x faster or something like that.


> I'm figuring out we might have had a great performance problem here: the
> cpu_info structure is allocated from kmem, which can borrow VA from the
> direct map. Since the direct map was mapped with 1GB superpages (or 2MB
> otherwise), it looks like you could get the whole gigabyte to fault all the
> time.

I don't know if that was true back in 2013 when I tested it, but as
you can see from that kludge I only pushed tss to a page of its own.

-uwe