Date: Thu, 21 Nov 1996 05:12:17 +0800 From: Peter Wemm <peter@spinner.dialix.com> Cc: Chris Csanady <ccsanady@friley216.res.iastate.edu>, Steve Passe <smp@csn.net>, freebsd-smp@freebsd.org Subject: Re: vm_page_alloc(ZERO): missing pages... Message-ID: <199611202112.FAA12954@spinner.DIALix.COM> In-Reply-To: Your message of "Thu, 21 Nov 1996 04:58:24 %2B0800." <199611202058.EAA12835@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > 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... Hmm, I just reread that and realised that I didn't state the implications clearly enough.. This is not merely an "oops, the smp kernel crashed/hung!" type problem. It's potentially an "Oh shit! It just destroyed all my filesystems and lost all my data!!!" type problem. The fact that we've not heard of it happening yet is probably an indication of several things: - the developers machines have gobs of ram, reducing the page stealing. - the P5 appears to have a smallish TLB, so there may be a relatively quick recycling of TLB slots, again reducing the window. - The TLB is flushed on a context switch, and potentially on every syscall. This is why we say "for developers only" amd don't reccomend it for general use. I personally strongly discourage it for critical systems.. Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611202112.FAA12954>