From owner-freebsd-arch Thu Feb 28 13:15: 6 2002 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 117CD37B42F for ; Thu, 28 Feb 2002 13:14:31 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1SLEQW38736; Thu, 28 Feb 2002 13:14:26 -0800 (PST) (envelope-from dillon) Date: Thu, 28 Feb 2002 13:14:26 -0800 (PST) From: Matthew Dillon Message-Id: <200202282114.g1SLEQW38736@apollo.backplane.com> To: Jeff Roberson Cc: Julian Elischer , Subject: Re: Slab allocator References: <20020228141318.J31751-100000@mail.chesapeake.net> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Ok, both of you have requested more comments. I have commented what I :felt were the trickier situations. Could you give me some examples of :what seems to be lacking documentation? I'm perfectly willing to add it, :but since I wrote the code most things seem perfectly intuitive to me. :-) : :Thanks, :Jeff Could you explain the change made (crinit() and crzero() calls) to kern/init_main.c ? Does uma_zalloc() automatically zero the returned memory? You replace MALLOC(..M_ZERO) in two places, example: - MALLOC(fp, struct file *, sizeof(struct file), M_FILE, M_WAITOK | M_ZERO ); + fp = uma_zalloc(file_zone, M_WAITOK); I recommend KASSERTing bucket_ub_ptr is in-bounds in vm/uma_core.c line 1403 (i.e. us_freecount and ub_ptr are coherent). I recommend KASSERTing that the uz_free_slab list is non-empty on line 1381. On line 82 of vm/uma_int.h you describe embedding a slab header in a Page. I could not find where in the code this embedding takes place (I looked for 'slab header' in the code but could not find anything related to the comment on line 82 of vm/uma_int.h In anycase, if you are embeddeding the slab header I recommend adding a magic number of the base of the slab header structure described in the comment and KASSERT()ing it as a sanity check. -- -- documentation -- -- uma_timeout line 185 uma_core.c. Could you describe what a 'working set calc.' is? What is a working set? In general, the comments at the head of the routines do not include context. For example, take hash_sfind(). 'Find a slab within a zone that has a matching data field'. What I would like to see is a comment like this: 'Find a slab within a zone that has a matching data field. This function is mainly used by the deallocator to locate the slab which owns an item data pointer.' Other examples. Line 266, the comment for hash_expand(), says what it does 'Expands the hash table for OFFPAGE zones', but does not say WHY it does it or HOW it does it. In anycase, this is general for all the routines. It would be nice if you did a once-over and clarified the context of the comment where it seems appropriate. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message