From owner-freebsd-current Wed Apr 3 04:26:27 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA09583 for current-outgoing; Wed, 3 Apr 1996 04:26:27 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA09570 for ; Wed, 3 Apr 1996 04:26:23 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA17145; Wed, 3 Apr 1996 22:15:32 +1000 Date: Wed, 3 Apr 1996 22:15:32 +1000 From: Bruce Evans Message-Id: <199604031215.WAA17145@godzilla.zeta.org.au> To: bde@zeta.org.au, toor@dyson.iquest.net Subject: Re: calcru: negative time: Cc: freebsd-current@freefall.freebsd.org, kuku@gilberto.physik.rwth-aachen.de, phk@critter.tfs.com Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >So we should probably make splvm: net_imask|bio_imask|tty_imask??? >(Keeping tty_imask mostly because of the possibility of some time in the >future, the tty code needing to do malloc(s)?) It's convenient to be able to call malloc(), but the prices is high: higher latency and more races to avoid and more bugs when you don't avoid the races. I'd like to make splvm() a no-op or splsoftclock() (mask only timeouts). I think splimp() _was_ completely correct because only the network interrupt handlers abused malloc(). This is stupid because the network drivers can afford to drop packets while the tty drivers can't, and the mallocations are mainly (only?) used to grow the pool of mbuf clusters so the only benefit is that the pool takes longer to reach its limit. >Really, if we wanted to optimize the situation, we could limit the malloc >code to net_imask (I don't think that anything else mallocs at interrupt >level), and the rest of the VM to net_imask|bio_imask? However, >we need to document that very very carefully for future maintainers. Like malloc(3) is very very carefully documented to not work in signal handlers? ;-) Bruce