From owner-freebsd-smp  Wed Dec  4 03:04:35 1996
Return-Path: owner-smp
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id DAA12160
          for smp-outgoing; Wed, 4 Dec 1996 03:04:35 -0800 (PST)
Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA12141
          for <smp@freebsd.org>; Wed, 4 Dec 1996 03:04:22 -0800 (PST)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.4/8.8.4) with ESMTP id TAA04123;
          Wed, 4 Dec 1996 19:03:39 +0800 (WST)
Message-Id: <199612041103.TAA04123@spinner.DIALix.COM>
To: "J.M. Chuang" <smp@bluenose.na.tuns.ca>
cc: smp@freebsd.org
Subject: Re: cvs commit: sys/i386/conf options.i386 
In-reply-to: Your message of "Tue, 03 Dec 1996 23:46:44 -0400."
             <199612040346.XAA15194@bluenose.na.tuns.ca> 
Date: Wed, 04 Dec 1996 19:03:39 +0800
From: Peter Wemm <peter@spinner.dialix.com>
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

"J.M. Chuang" wrote:
> > >   Modified:    i386/conf  options.i386
> > >   Log:
> > >   list SMP_INVLTLB as "should be working"
> > 
> > Incidently, I'd appreciate hearing if this works for other people
> > as well.  If this works as I suspect it does, it will dramatically
> > reduce the chances of filesystem and process memory corruption due
> > to page stealing and should be a major reliability improvement.
> > 
> No more coredump for IDE with options SMP_INVLTLB. Great Work!

Hey, wow!  This is an unexpected bonus!  I never expected this to be
a side effect, but now that I think about it, it makes sense.  The
SCSI system generally uses bus-mastering to send the data directly
to the destination physical address, while the IDE driver maps the
target page into KVM and does PIO to write it.  And since it's changing
mappings, it would be very vulnerable to stale tlb data.

The remaining problem is that we are currently doing way too many global
invltlb() calls.  John Dyson has already indicated that we can be a lot
more selective about which ones we propagate to other cpus.

Right now, I can see the IPI's (which show up as "irq0" interrupts on
systat -vmstat) peaking in the 2000+ per second range which is rather
excessive..  This is a performance problem, not a reliability one.

> Jim

Cheers,
-Peter