Date: Thu, 21 Nov 1996 04:58:24 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: Chris Csanady <ccsanady@friley216.res.iastate.edu> Cc: Steve Passe <smp@csn.net>, freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... Message-ID: <199611202058.EAA12835@spinner.DIALix.COM> In-Reply-To: Your message of "Wed, 20 Nov 1996 14:50:04 CST." <199611202050.OAA02373@friley216.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Csanady wrote: > >Also, how much paging is taking place? We are not propagating TLB flushes > >to all cpu's yet (needs APIC IPI's to work). > > A great deal of paging. I was running a benchmark (hint) which beats on the > memory quite hard. VM as well. Besides being a wonderful benchmark, I also > use it every now and then to try to break things. :) Err, well, in this case, I'd suggest the following saying is appropriate: Patient: "Doctor! Doctor! It hurts when I do this.." Doctor: "Well, don't do it then.." > Are the lacking TLB flushes very harmful? How hard would this be to > implement? Yes, and potentially rather nasty. :-( Here's why: CPU 1: Running in user mode CPU 2: enters kernel, frees up pages that belong to the process that CPU 1 is running, reassigns them elsewhere, flushes it's TLB and uses the new mappings. CPU 1: blissfully unaware while the TLB cache holds.. Continues to use the page that it thinks it owns, but might now be being used to write an inode or something... There is a race between the page mappings being changed and the next TLB flush on the other cpus. This window opens up much wider when there is paging, or page stealing going on. > Chris Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611202058.EAA12835>