Date: Tue, 26 Feb 2002 02:09:34 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Alfred Perlstein <alfred@FreeBSD.ORG> Cc: current@FreeBSD.ORG, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, Matthew Dillon <dillon@apollo.backplane.com> Subject: RE: How to fix malloc. Message-ID: <XFMail.020226020934.jhb@FreeBSD.org> In-Reply-To: <20020223211449.GJ80761@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Feb-02 Alfred Perlstein wrote: > * Matthew Dillon <dillon@apollo.backplane.com> [020223 12:51] wrote: >> >> :Here is the most up-to-date version of pgrp/session lock (at Change 6700): >> : >> :http://people.FreeBSD.org/~tanimura/patches/pgrp10.diff.gz >> : >> :I would like to commit this on the next Sunday. Otherwise, my patch >> :would conflict with other patches, especially tty. >> : >> :-- >> :Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> >> >> Do you have any plans to get pgdelete() out from under Giant? That >> would allow leavepgrp(), doenterpgrp(), enterpgrp(), enterthispgrp(), >> setsid() (mostly) to be taken out from under Giant, and perhaps a few >> others. >> >> I was thinking of simply having a free list of sessions and process >> groups, locked by PGRPSESS_XLOCK(). pgdelete() would then not have >> to call FREE() and setsid() would almost always be able to pull a new >> structure of the appropriate free list and thus not have to obtain Giant >> for the MALLOC. > > All these per-subsystem free-lists are making me nervous in both > complexity and wasted code... > > Ok, instead of keeping all these per-subsystem free-lists here's what > we do: > > In kern_malloc:free() right at the point of > if (size > MAXALLOCSAVE) we check if we have Giant or not. > if we do not then we simply queue the memory > however, if we do then we call into kmem_free with all the queued memory. > > This ought to solve the issue without making us keep all these > per-cpu caches. > > By the way, since "MAXALLOCSAVE" is some multiple of PAGE_SIZE, we > really don't have to worry about it when freeing small structures > although that puts evilness into malloc(9) consumers. > > Can you please consider that instead of continueing down this path > of per-subsystem caches? Just as a general heads up, the slab memory allocator Jeff Roberson is working on will not need Giant for the free path, so can we just live with Giant locking around free() for now rather than adding in a bunch of temporary hacks to reinvent the wheel that we have to go back and remove later? -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020226020934.jhb>