Re: 4.7 vs 5.2.1 SMP/UP bridging performance

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 05/06/04

  • Next message: Julian Elischer: "Re: nVidia FX Support?" 
    To: freebsd-current@FreeBSD.org
Date: Thu, 6 May 2004 14:47:14 -0400

    On Thursday 06 May 2004 02:26 pm, Andrew Gallatin wrote:
    > John Baldwin writes:
    > > and lfence is only on PIV+. I don't recall when mfence first appeared..
    > > perhaps PII? If the lock is really expensive, then perhaps we could
    > > make atomic_cmpset() be actual functions (ugh) rather than inlines that
    > > did a branch to use foofence for PIV rather than the default. The
    > > branches would suck, but it might be faster than the lock. Of course,
    > > this would greatly pessimize non-PIV.
    >
    > According to http://www.sandpile.org/ia32/coherent.htm,
    > both mfence and lfence require SSE2, so sfence has the broadest
    > coverage.
    >
    > But since only P4 needs it, and since lfence is ~25% cheaper, maybe
    > there should be a separate config option for it, and it should be a
    > straight conditional compile option for those of us cursed w/P4s.

    That could work I guess. Just can't stick it in GENERIC.

    options INTEL_MADE_MY_PIV_A_TORTOISE

    or some such. :) 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Julian Elischer: "Re: nVidia FX Support?"

    Relevant Pages

    • Re: 4.7 vs 5.2.1 SMP/UP bridging performance
      ... If the lock is really expensive, ... > branch to use foofence for PIV rather than the default. ... But since only P4 needs it, and since lfence is ~25% cheaper, maybe ...
      (freebsd-current)
    • Re: 4.7 vs 5.2.1 SMP/UP bridging performance
      ... > John Baldwin writes: ... >> perhaps PII? ... but it might be faster than the lock. ...
      (freebsd-current)
    • Re: rusage breakdown and cpu limits.
      ... On Tue, 29 May 2007, John Baldwin wrote: ... runtime and tick counts ... I have indirectly shown that this approach will not yield sufficient results by decreasing the scope of the sched lock in other ways. ... This would gate context switches in the same way that a global scheduler lock would, except not over as long of a period. ...
      (freebsd-arch)
    • Re: file locking.
      ... On Thu, 16 Aug 2007, John Baldwin wrote: ... I just introduced an extra flag so I could remove the race from dropping the lock inbetween operations and get an accurate count of how big the array needs to be. ... What's more troubling is the continued erosion of support for libkvm as it ... Well shaving off two pointers gets us into cacheline size for struct file which has some perf improvement. ...
      (freebsd-arch)
    • Re: exclusive sleep mutex pcm0 (sound cdev) r = 0
      ... On 24 Feb, John Baldwin wrote: ... >> A thread may not own a shared lock and an exclusive lock ... as well as things like malloc(). ... >> concerned about causing a deadlock by violating the sx usage rules. ...
      (freebsd-current)