From owner-freebsd-hackers Fri Aug 25 10:24:03 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id KAA18774 for hackers-outgoing; Fri, 25 Aug 1995 10:24:03 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id KAA18768 for ; Fri, 25 Aug 1995 10:24:01 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA11901; Fri, 25 Aug 95 11:25:38 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9508251725.AA11901@cs.weber.edu> Subject: Re: sys/malloc.h To: davidg@Root.COM Date: Fri, 25 Aug 95 11:25:37 MDT Cc: hackers@freebsd.org In-Reply-To: <199508250218.TAA13550@corbin.Root.COM> from "David Greenman" at Aug 24, 95 07:18:10 pm X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk > >We may even want to reconsider why spl/splx is needed to guard around > >the malloc()/free() anyway -- obviously to allow allocation/freeing > >in interrupt code. Perhaps we should adopt an architecture of prealloc > >and free later for interrupt level alloc/free? > > It's because mallocs and frees have to happen in the networking code at > interrupt time. It would be tremendously wasteful to pre-alloc megabytes of > memory just to avoid this. Are you saying megabytes of memory worth of packets come in at interrupt time before the buffers have a chance to be processed and subsequently freed? If that's the case, then the "megabytes of memory" are allocated anyway, and I don't see how changing when this happens is wasteful. It seems that this is just a hack to handle bursting of data, and even then it's a hack that only works for non-interrupt time servicing of interrupt data -- something the drivers aren't architected for. If they were architected this way, then you'd have a soft interrupt to service (and free) the buffer -- not in interrupt mode. On the other hand, if you are referring to something like the NFS server calling VOP_READDIR, which necessitates calling malloc/free each time it is called, well I agree that's wasteful and shouldn't be preallocated. By the same token, it shouldn't be allocated at all; it should be using a stack variable for the discardable buffer it uses to temporarily save the directory search results while processing them into an RPC reply. In any case, there doesn't seem to be a significant handicap to requiring explicit allocation of interrupt time memory. In point of fact, SMP will require this in any case... or a memory domain private to interrupt level as opposed to private to a particular CPU (which amounts to permananet allocation, since freeing is also limited to interrupt level, unless you want to trade I/O for CPU bandwidth, and an SMP box is rarely I/O bound...). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.