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
