Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Sep 2002 12:39:32 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Bruce Evans <bde@zeta.org.au>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/kern vfs_bio.c src/sys/sys bio.h 
Message-ID:  <200209151939.g8FJdWfo057422@apollo.backplane.com>
References:   <80183.1032075272@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
:
:I don't care what you think until you have at least found out what
:what we are talking about here.
:
:You could start out by finding the places which call biowait() in
:the first place, then you'll probably (no guarantees) see how
:marginal the issue under discussion is.
:
:Preferably you'll just leave me alone instead.
:
:-- 
:Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20

    Ha.  Preferably I won't have to clean this up a year down the line
    when complaints start to mount about certain operations taking far
    longer then they should.

    You should realize, Poul, that without using a mutex there is a fairly
    large window where this race can be lost if the interrupt setting
    the BIO_DONE occurs on a different cpu then the process waiting for
    completion.  It isn't just a few instructions.

    You are creating a chunk of code to try to avoid making a mutex 
    call.  It's been done before, and it will probably be done again, and
    it's a huge mistake.  For better or for worse we are using the mutex
    mechanism for our interlocks and if we start doing end-runs around
    the mechanism out of a desire to gain performance we are going to wind
    up with not one, not two, not three, but DOZENS of different mechanisms
    all throughout the code.  None documented, and all creating 
    non-deterministic code paths and delays.   I may not be happy with
    our mutexes, but I am even less happy with dozens of different end-runs
    around them.

    At least if you use a mutex you have something that is deterministic
    and you are using common interlock code whos efficiencies can be attacked
    in just one place later on.  By not using a mutex you are just creating
    a mess of work that someone will have to fix later on.  It's that simple.

    (And remember, I'm usually the one who advocates for high performance
    solutions!).

						-Matt


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209151939.g8FJdWfo057422>