:       You cannot be pre-empted by an interrupt if you are holding a spin
: mutex, AFAIK, even under present implementation.

    Since spin mutexes are going to be held all over the place, this 
    type of restriction would seem to be detrimental.  If you can do all
    the checking up-front it is also unnecessary.

:       What happens if we get an interrupt, we're thinking about servicing
:it, about to check whether we're already holding a mutex that may potentially
:be used inside the mainline int routine, and another CPU becomes idle?
:In this particular case, let's say that we decide that we have to set
:ipending and iret immediately, because we're already holding a potential

    You could, but you are talking about a very small window of opportunity
    assuming that we are running similar code to what we have now in regards
    to assigning the interrupts to a cpu.  In 4.x we assign interrupts to
    whichever cpu is holding Giant.  With mutexes we would want to assign
    interrupts to whichever cpu is idle and if no cpu is idle we round-robin
    the interrupt assignments (e.g. cpu takes interrupt, assigns all 
    interrupts to the next cpu if no cpus are idle).  With that in place,
    the best course is almost certainly going to be to do nothing ... that is,
    take the interrupt even though it might not be optimal.

    If once every X thousand interrupts we happen to hit a case where a cpu
    remains idle when it doesn't have to be, who gives a flying f**k if
    that one interrupt is non-optimal?  I'm not kidding... that sort of
    case is not a problem that needs to be solved.

:       Also, some mainline interrupt code may need to acquire a really
:large number of locks, but only in some cases. Let's say we have to first
:check if we have a free cached buffer sitting somewhere, and if not, malloc()

    None of our current interrupt code needs to aquire a huge number of
    locks, and if some piece of interrupt code is so complex that it does,
    it should be relegated to a software interrupt (e.g. like the TCP stack).
    Lets not create problems where they don't exist.  If one of our subsystems
    happened to be require more complexity - for example, the I/O completion
    handling (biodone() code), it's a solveable problem.

    Simplification is what is needed here.  Creating a complex solution to
    a complex problem only results in a mess.  Simplifying the problem so
    that it covers most of your codebase and then focusing on the one or two
    cases it doesn't cover would seem to be a better way of dealing with
    the issue.

:lock operations, but only in the case where we lack the cached buffer to
:allocate it. There is no practical way of telling up front whether or not
:we'll have to malloc(), so I'm wondering how efficiently we would be able
:to predict in cases such as these?
: Bosko Milekic

    It could very well be that for an interrupt we might need to list 
    two mutexes --- one for the memory subsystem and one for the interrupt's
    subsystem.  It would be nice if we could get away with one, but having
    to list two or even three mutexes would not be much of a burden on
    the interrupt code.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to