From owner-freebsd-arch Tue Feb 4 3:29:53 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 105C837B401 for ; Tue, 4 Feb 2003 03:29:52 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EFBA43F93 for ; Tue, 4 Feb 2003 03:29:51 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h14BToYu019573 for ; Tue, 4 Feb 2003 12:29:50 +0100 (CET) (envelope-from phk@freebsd.org) To: arch@freebsd.org Subject: length of device names. From: phk@freebsd.org Date: Tue, 04 Feb 2003 12:29:50 +0100 Message-ID: <19572.1044358190@critter.freebsd.dk> 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 There are some irritating implications of making device names truly variable size, and I am not yet comfortable making the semantic changes it causes, people calle makedev() and make_dev() from the damnest places. In fact, I am not even convinced doing the work would have a positive payoff in the end compared to sticking with KISS and just taking the memory hit for a longer default buffer. I decided to increase the limit to 63 characters for now, and revisit the issue if this limit ever becomes a problem. I personally expect and hope that any device name approaching than 63 characters would hit against other (esthetical) boundaries first. We currently allocate 50 dev_t's at compile time (to be able to make it until malloc(9) works) and the rest with malloc(9). The current size of a dev_t is 140 bytes + space for the name, so in theory we can allow for 116 bytes long names at a net cost of only 50 times the increase since malloc(9) already allocates us 256 bytes buckets, so the net cost of this change was 2400 bytes. Summary: I'm shelving the unlimited name length for now, hoping that 63 or subsequently 116 will be enough to cater for our needs. Poul-Henning In message <200302041107.h14B7ST1060100@repoman.freebsd.org>, Poul-Henning Kamp writes: >phk 2003/02/04 03:07:28 PST > > Modified files: > sys/sys param.h > Log: > Increase the allowed length of device names to 63 characters. > > This is a band-aid while I fret over how much breakage removing the > restriction entirely will result in. > > Please note that this is still a limit for the entire pathname > relative to the mountpoint of devfs, so the length of "/dev/fd/3" > is 4 characters. > > Revision Changes Path > 1.142 +1 -1 src/sys/sys/param.h > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 7:46: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74EEE37B401; Tue, 4 Feb 2003 07:46:00 -0800 (PST) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93BAF43F93; Tue, 4 Feb 2003 07:45:59 -0800 (PST) (envelope-from mi+mx@aldan.algebra.com) Received: from mi.us.murex.com (250-217.customer.cloud9.net [168.100.250.217]) by corbulon.video-collage.com (8.12.7/8.12.7) with ESMTP id h14FjlM3065493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 4 Feb 2003 10:45:51 -0500 (EST) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: arch@FreeBSD.org, Alfred Perlstein , Wes Peters Subject: dlclose() vs. atexit() Date: Tue, 4 Feb 2003 10:46:13 -0500 User-Agent: KMail/1.4.3 Cc: Mario Sergio Fujikawa Ferreira References: <200302030506.h1356Nha011918@repoman.freebsd.org> <1044319099.358.57.camel@zaphod.softweyr.com> <20030204082625.GB85104@elvis.mu.org> In-Reply-To: <20030204082625.GB85104@elvis.mu.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_1TJS4DHZQUSZ02JIZ5RR" Message-Id: <200302041046.13767.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) 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 --------------Boundary-00=_1TJS4DHZQUSZ02JIZ5RR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit [Moved to -arch] On Tuesday 04 February 2003 03:26 am, Alfred Perlstein wrote: = * Wes Peters [030203 23:41] wrote: = > On Mon, 2003-02-03 at 18:58, Mikhail Teterin wrote: = > > There remains an unresolved issue with mplayer on FreeBSD -- some = > > of the libraries it dlopens and dlcloses are calling atexit() in = > > between with their own functions. = > > = > > This causes SEGFAULTs in exit(), which tries to call those = > > functions. The application catches the signals and would not quit = > > until SIGKILL-ed. = > > = > > This does not affect Linux, where, reportedly, calls to atexit() = > > are treated differently if made from dlopened code. I'm not sure = > > how best to fix this (Call _exit()? Remove signal handlers before = > > exit()?), but something needs to be done... = > I think ideally we'd want dlclose to be able to deinstall any = > atexit handlers that were installed by library functions. The = > most straight- forward path to this I can see is an atexit-remove = > call that can be passed a start and end address and will remove = > any function references found between the two. dlclose could call = > this function with the start and end addresses of the library text = > segment to remove any exit handlers in the library code space. = > I can probably take a look at this later in the week if this seems = > like a reasonable approach. = Please see if you can emulate the glibc behaviour just to ease = porting. I think that means you must actually call the atexit handler, = not just deregister it. Last time I brought this up, it was not clear, what The Right Thing to do is. Are these details mandatated by some standard out there, or is everyone on their own, and we should, indeed, do what Linux does, to not increase the enthropy? Should, for example, exit handlers, which will still be valid after the dlclose() still be called at dlclose() or at the actual exit()? How about atexit() calls made between dlopen() and dlclose(), and not by the library but by the application, or by another library? Have each library get its own list of exit-handlers? Or should it still be a global list, but examined by both dlclose() and exit() -- if an item on the list is about to become invalid after dlclose() (how can we know, BTW?), have dlclose() call it -- otherwise, leave it alone? That is what Solaris is doing, apparently. From their atexit(3c) The atexit() function registers the function pointed to by func to be called without arguments on normal termination of the program or when the object defining the function is unloaded. [...] On process exit, functions are called in the reverse order of their registration. On object unloading, any functions belonging to an unloadable object are called in the reverse order of their registration. The Solaris' approach seems the most robust. The Linux' one fails, when the exit handler belongs to another library. Attached are two files, which illustrate this -- even if somewhat artificially. . the main program dlopens two libraries (both built from the same source); . it then passes the library number (integer) -- for reporting, and the address of the handler _found in the other library_ to each one; . the libraries both register each other's functions as handlers; . the application unloads both libraris. On FreeBSD both libraries are quietly unloaded, and the application SEGFAULTs in exit(). On Linux, the crash happens at the second unload, which tries to call the handler from the first library. On Solaris everything runs to completion, which -- unless it violates some standard -- makes it the most appealing implementation (hostnames edited out): [...] 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Jan 8 19:15:03 EST 2003 [....] Loading the libraries ./l0.so loaded as 0x28064200 ./l1.so loaded as 0x28064300 Library 0 calling atexit(0x2813a6f0) Library 1 calling atexit(0x281386f0) Unloading the libraries 0x28064200 unloaded 0x28064300 unloaded Libraries unloaded. Returning Segmentation fault Linux [...] 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux Loading the libraries ./l0.so loaded as 0x8049ad0 ./l1.so loaded as 0x8049e00 Library 0 calling atexit(0x40016788) Library 1 calling atexit(0x40014788) Unloading the libraries Exit handler 0x40016788 of library 1 is invoked 0x8049ad0 unloaded Segmentation fault (core dumped) SunOS [...] 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R Loading the libraries ./l0.so loaded as ff3a1458 ./l1.so loaded as ff3a17b8 Library 0 calling atexit(ff260380) Library 1 calling atexit(ff350380) Unloading the libraries Exit handler ff350380 of library 0 is invoked ff3a1458 unloaded Exit handler ff260380 of library 1 is invoked ff3a17b8 unloaded Libraries unloaded. Returning Yet another plan would be to have the atexit() call simply increase the ref-count of the library a handler is from, so it will not actually be unloaded by dlclose(). But that will be yet another implementation... -mi --------------Boundary-00=_1TJS4DHZQUSZ02JIZ5RR Content-Type: text/x-csrc; charset="iso-8859-1"; name="l.c" Content-Transfer-Encoding: 7bit Content-Description: Both l0.so and l1.so are built from this file Content-Disposition: attachment; filename="l.c" static int mynumber; void handler(void) { printf("Exit handler %p of library %d is invoked\n", handler, mynumber); } void in(int i, void (*func)(void)) { mynumber = i; printf("Library %d calling atexit(%p)\n", mynumber, func); if (atexit(func)) { perror("atexit"); _exit(2); } } --------------Boundary-00=_1TJS4DHZQUSZ02JIZ5RR Content-Type: text/x-csrc; charset="iso-8859-1"; name="main.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="main.c" #include #include #include #include int main() { struct { void *lib; void (*handler)(void); void (*in)(int, void (*)(void)); } l[2]; int i; system("uname -a"); puts("Loading the libraries"); for (i = 0; i < 2; i++) { char lname[8]; sprintf(lname, "./l%d.so", i); l[i].lib = dlopen(lname, RTLD_LAZY); if (l[i].lib == NULL) { fprintf(stderr, "%s: %s\n", lname, dlerror()); _exit(1); } printf("%s loaded as %p\n", lname, l[i].lib); l[i].handler = dlsym(l[i].lib, "handler"); if (l[i].handler == NULL) { fprintf(stderr, "%s: dlsym for ``handler'': %s\n", lname, dlerror()); _exit(1); } l[i].in = dlsym(l[i].lib, "in"); if (l[i].in == NULL) { fprintf(stderr, "%s: dlsym for ``in'': %s\n", lname, dlerror()); _exit(1); } } l[0].in(0, l[1].handler); l[1].in(1, l[0].handler); puts("Unloading the libraries"); for (i = 0; i < 2; i++) { dlclose(l[i].lib); printf("%p unloaded\n", l[i].lib); } puts("Libraries unloaded. Returning"); return 0; } --------------Boundary-00=_1TJS4DHZQUSZ02JIZ5RR-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 8:25:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDCE437B401 for ; Tue, 4 Feb 2003 08:25:19 -0800 (PST) Received: from arpa.com (arpa.com [199.245.173.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8343743F75 for ; Tue, 4 Feb 2003 08:25:19 -0800 (PST) (envelope-from wd@arpa.com) Received: from localhost (localhost [127.0.0.1]) by arpa.com (Postfix) with ESMTP id C9D84CAA for ; Tue, 4 Feb 2003 10:25:13 -0600 (CST) Received: by arpa.com (Postfix, from userid 102) id 2DBBCCA7; Tue, 4 Feb 2003 10:25:13 -0600 (CST) Date: Tue, 4 Feb 2003 10:25:13 -0600 From: Chip Norkus To: arch@freebsd.org Subject: Re: dlclose() vs. atexit() Message-ID: <20030204162513.GB22642@arpa.com> References: <200302030506.h1356Nha011918@repoman.freebsd.org> <1044319099.358.57.camel@zaphod.softweyr.com> <20030204082625.GB85104@elvis.mu.org> <200302041046.13767.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200302041046.13767.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.4i X-Virus-Scanned: by AMaViS snapshot-20020531 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 On Tue Feb 04, 2003; 10:46AM -0500 Mikhail Teterin propagated the following: [snip] > > Yet another plan would be to have the atexit() call simply increase the > ref-count of the library a handler is from, so it will not actually be > unloaded by dlclose(). But that will be yet another implementation... > I'm not sure this would be a good idea. I have a program which uses dynamic libraries to introduce code, and which can unload or reload them at any time and keep on running. I am especially worried about the reload case, because what often happens is that an old version of the .so is unloaded (dlclosed) and then a new version is loaded (dlopened). If the old version stays around, I'm afraid there would be some symbol collision. Correct me if I'm wrong, though. I think the Solaris approach you mentioned above is by far the best and most correct sounding approach. > -mi > -wd -- chip norkus; unix geek and programmer; wd@arpa.com "question = (to) ? be : !be;" --Shakespeare http://telekinesis.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 8:43:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F8EA37B401 for ; Tue, 4 Feb 2003 08:43:48 -0800 (PST) Received: from dire.bris.ac.uk (dire.bris.ac.uk [137.222.10.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2567A43F75 for ; Tue, 4 Feb 2003 08:43:47 -0800 (PST) (envelope-from Jan.Grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Tue, 4 Feb 2003 16:43:36 +0000 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 3.16 #1) id 18g69h-0005uH-00; Tue, 04 Feb 2003 16:42:41 +0000 Date: Tue, 4 Feb 2003 16:42:41 +0000 (GMT) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: Chip Norkus Cc: arch@freebsd.org Subject: Re: dlclose() vs. atexit() In-Reply-To: <20030204162513.GB22642@arpa.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Tue, 4 Feb 2003, Chip Norkus wrote: > On Tue Feb 04, 2003; 10:46AM -0500 Mikhail Teterin propagated the following: > > [snip] > > > > Yet another plan would be to have the atexit() call simply increase the > > ref-count of the library a handler is from, so it will not actually be > > unloaded by dlclose(). But that will be yet another implementation... > > > > I'm not sure this would be a good idea. I have a program which > uses dynamic libraries to introduce code, and which can unload or > reload them at any time and keep on running. I am especially worried > about the reload case, because what often happens is that an old > version of the .so is unloaded (dlclosed) and then a new version > is loaded (dlopened). If the old version stays around, I'm afraid > there would be some symbol collision. Correct me if I'm wrong, > though. > > I think the Solaris approach you mentioned above is by far the best > and most correct sounding approach. I agree; I've done similar work with dlopened libraries which were "updated" over time, dynamically. The atexit() / dlclose() behaviour seems robust and "does the right thing". If you want more complex behaviour (eg, persisting library state while you update a dynamic library) then you have to roll your own. That's not a big deal. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ There's no convincing English-language argument that this sentence is true. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 11:13:36 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6163A37B6F9; Tue, 4 Feb 2003 11:13:34 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6301843F85; Tue, 4 Feb 2003 11:13:33 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0327.cvx21-bradley.dialup.earthlink.net ([209.179.193.72] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18g8Vd-0000Gk-00; Tue, 04 Feb 2003 11:13:30 -0800 Message-ID: <3E401082.6C6512F8@mindspring.com> Date: Tue, 04 Feb 2003 11:12:02 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mikhail Teterin Cc: arch@FreeBSD.org, Alfred Perlstein , Wes Peters , Mario Sergio Fujikawa Ferreira Subject: Re: dlclose() vs. atexit() References: <200302030506.h1356Nha011918@repoman.freebsd.org> <1044319099.358.57.camel@zaphod.softweyr.com> <20030204082625.GB85104@elvis.mu.org> <200302041046.13767.mi+mx@aldan.algebra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4a9111c3053963c55c9b0d9bca052c179350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Mikhail Teterin wrote: > Last time I brought this up, it was not clear, what The Right Thing to > do is. Are these details mandatated by some standard out there, or is > everyone on their own, and we should, indeed, do what Linux does, to not > increase the enthropy? > > Should, for example, exit handlers, which will still be valid after the > dlclose() still be called at dlclose() or at the actual exit()? How > about atexit() calls made between dlopen() and dlclose(), and not by the > library but by the application, or by another library? Have each library > get its own list of exit-handlers? > > Or should it still be a global list, but examined by both dlclose() > and exit() -- if an item on the list is about to become invalid after > dlclose() (how can we know, BTW?), have dlclose() call it -- otherwise, > leave it alone? FWIW, the way Windows handles this is to have various entry point to manage this: ProcessAttach Called after a process attaches to a shared object ProcessDetach Called before a process detaches a shared object ThreadAttach Called after a thread attaches to a shared object ThreadDetach Called before a thread detaches a shared object The key here is that all processes have at least one thread. These are really the entry points, not the atexit(), that should be used. Right now, FreeBSD can at least do the Process[Attach|Detach] for dlopen'ed objects, by abusing the .init and .fini sections, and/or abusing the .ctor and .dtor sections. Probably, this is the correct approach, overall, but requires some small mod to crt*.c to make it entirely happy (declaring multiple .init/.fini sections displaces, rather than aggregating them, as only the first entry in the linker set is invoked, not the whole list, and using the .ctor/.dtor approach requires using the C++ crt*.c in the C case). I've actually posted code to abuse .init/.fini to this list in the past, a part of creating a static libdlopen. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 11:42:55 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4465A37B401; Tue, 4 Feb 2003 11:42:54 -0800 (PST) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE87343F43; Tue, 4 Feb 2003 11:42:52 -0800 (PST) (envelope-from fjoe@iclub.nsu.ru) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 18g8xr-00085E-00; Wed, 05 Feb 2003 01:42:39 +0600 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 18g8xr-00084q-00; Wed, 05 Feb 2003 01:42:39 +0600 Received: from iclub.nsu.ru (fjoe@localhost [127.0.0.1]) by iclub.nsu.ru (8.12.6/8.12.6) with ESMTP id h14JgURV063080; Wed, 5 Feb 2003 01:42:30 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.12.6/8.12.6/Submit) id h14JgTv8063079; Wed, 5 Feb 2003 01:42:29 +0600 (NS) Date: Wed, 5 Feb 2003 01:42:29 +0600 From: Max Khon To: Mikhail Teterin Cc: arch@freebsd.org, Alfred Perlstein , Wes Peters , Mario Sergio Fujikawa Ferreira Subject: Re: dlclose() vs. atexit() Message-ID: <20030205014229.A62172@iclub.nsu.ru> References: <200302030506.h1356Nha011918@repoman.freebsd.org> <1044319099.358.57.camel@zaphod.softweyr.com> <20030204082625.GB85104@elvis.mu.org> <200302041046.13767.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200302041046.13767.mi+mx@aldan.algebra.com>; from mi+mx@aldan.algebra.com on Tue, Feb 04, 2003 at 10:46:13AM -0500 X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 X-Envelope-To: mi+mx@aldan.algebra.com, arch@freebsd.org, bright@mu.org, wes@softweyr.com, lioux@freebsd.org 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 hi, there! > Yet another plan would be to have the atexit() call simply increase the > ref-count of the library a handler is from, so it will not actually be > unloaded by dlclose(). But that will be yet another implementation... this will break applications which want to reload some of the dlopen'ed modules /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 12: 5:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADF4B37B401; Tue, 4 Feb 2003 12:05:43 -0800 (PST) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDAE143E4A; Tue, 4 Feb 2003 12:05:39 -0800 (PST) (envelope-from mi+mx@aldan.algebra.com) Received: from mi.us.murex.com (250-217.customer.cloud9.net [168.100.250.217]) by corbulon.video-collage.com (8.12.7/8.12.7) with ESMTP id h14K5RM3067126 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 4 Feb 2003 15:05:31 -0500 (EST) (envelope-from mi+mx@aldan.algebra.com) Content-Type: text/plain; charset="iso-8859-1" From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Max Khon Subject: Re: dlclose() vs. atexit() Date: Tue, 4 Feb 2003 15:05:53 -0500 User-Agent: KMail/1.4.3 Cc: arch@freebsd.org, Alfred Perlstein , Wes Peters , Mario Sergio Fujikawa Ferreira References: <200302030506.h1356Nha011918@repoman.freebsd.org> <200302041046.13767.mi+mx@aldan.algebra.com> <20030205014229.A62172@iclub.nsu.ru> In-Reply-To: <20030205014229.A62172@iclub.nsu.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200302041505.53352.mi+mx@aldan.algebra.com> X-Scanned-By: MIMEDefang 2.21 (www . roaringpenguin . com / mimedefang) 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 On Tuesday 04 February 2003 02:42 pm, Max Khon wrote: = hi, there! = = > Yet another plan would be to have the atexit() call simply increase the = > ref-count of the library a handler is from, so it will not actually be = > unloaded by dlclose(). But that will be yet another implementation... = = this will break applications which want to reload some = of the dlopen'ed modules I guess, I'm especially slow today. How will it break them? That is what Solaris appears to be doing, BTW -- calling the exit-handler at dlclose(), but leaving the library in memory: SunOS [...] 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R Loading the libraries ./l0.so loaded as ff3a1458 ./l1.so loaded as ff3a17b8 Library 0 calling atexit(ff260380) Library 1 calling atexit(ff350380) Unloading the libraries Exit handler ff350380 of library 0 is invoked ff3a1458 unloaded Exit handler ff260380 of library 1 is invoked ff3a17b8 unloaded Libraries unloaded. Returning See, the exit handler for library 1 is called and does not crash, even though it is defined in the already dlclosed library 0... -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 12:45: 4 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 692AC37B405; Tue, 4 Feb 2003 12:45:02 -0800 (PST) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id E254443F75; Tue, 4 Feb 2003 12:44:58 -0800 (PST) (envelope-from fjoe@iclub.nsu.ru) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 18g9vz-0003e2-00; Wed, 05 Feb 2003 02:44:47 +0600 Received: from iclub.nsu.ru ([193.124.215.97] ident=root) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 18g9vy-0003dt-00; Wed, 05 Feb 2003 02:44:46 +0600 Received: from iclub.nsu.ru (fjoe@localhost [127.0.0.1]) by iclub.nsu.ru (8.12.6/8.12.6) with ESMTP id h14KidRV064666; Wed, 5 Feb 2003 02:44:39 +0600 (NS) (envelope-from fjoe@iclub.nsu.ru) Received: (from fjoe@localhost) by iclub.nsu.ru (8.12.6/8.12.6/Submit) id h14KiYDS064665; Wed, 5 Feb 2003 02:44:34 +0600 (NS) Date: Wed, 5 Feb 2003 02:44:34 +0600 From: Max Khon To: Mikhail Teterin Cc: arch@freebsd.org, Alfred Perlstein , Wes Peters , Mario Sergio Fujikawa Ferreira Subject: Re: dlclose() vs. atexit() Message-ID: <20030205024434.A64330@iclub.nsu.ru> References: <200302030506.h1356Nha011918@repoman.freebsd.org> <200302041046.13767.mi+mx@aldan.algebra.com> <20030205014229.A62172@iclub.nsu.ru> <200302041505.53352.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200302041505.53352.mi+mx@aldan.algebra.com>; from mi+mx@aldan.algebra.com on Tue, Feb 04, 2003 at 03:05:53PM -0500 X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT,USER_AGENT_MUTT version=2.43 X-Envelope-To: mi+mx@aldan.algebra.com, arch@freebsd.org, bright@mu.org, wes@softweyr.com, lioux@freebsd.org 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 hi, there! On Tue, Feb 04, 2003 at 03:05:53PM -0500, Mikhail Teterin wrote: > = > Yet another plan would be to have the atexit() call simply increase the > = > ref-count of the library a handler is from, so it will not actually be > = > unloaded by dlclose(). But that will be yet another implementation... > = > = this will break applications which want to reload some > = of the dlopen'ed modules > > I guess, I'm especially slow today. How will it break them? That is > what Solaris appears to be doing, BTW -- calling the exit-handler at > dlclose(), but leaving the library in memory: > > SunOS [...] 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R > Loading the libraries > ./l0.so loaded as ff3a1458 > ./l1.so loaded as ff3a17b8 > Library 0 calling atexit(ff260380) > Library 1 calling atexit(ff350380) > Unloading the libraries > Exit handler ff350380 of library 0 is invoked > ff3a1458 unloaded > Exit handler ff260380 of library 1 is invoked > ff3a17b8 unloaded > Libraries unloaded. Returning > > See, the exit handler for library 1 is called and does not crash, even > though it is defined in the already dlclosed library 0... ah. if refcount will be decremented and checked for 0 (with possible dlclose call) after each call to exit function then there is no problems. /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 14:52:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FF0D37B401; Tue, 4 Feb 2003 14:52:47 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 587C843E4A; Tue, 4 Feb 2003 14:52:45 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id h14MqaP4044141; Tue, 4 Feb 2003 17:52:36 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 4 Feb 2003 17:52:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: phk@freebsd.org Cc: arch@freebsd.org Subject: Re: length of device names. In-Reply-To: <19572.1044358190@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Sounds reasonable to me. I just wanted longer device names, I didn't want unlimited ones. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories On Tue, 4 Feb 2003 phk@freebsd.org wrote: > > There are some irritating implications of making device names truly > variable size, and I am not yet comfortable making the semantic > changes it causes, people calle makedev() and make_dev() from the > damnest places. > > In fact, I am not even convinced doing the work would have a positive > payoff in the end compared to sticking with KISS and just taking > the memory hit for a longer default buffer. > > I decided to increase the limit to 63 characters for now, and revisit > the issue if this limit ever becomes a problem. I personally expect > and hope that any device name approaching than 63 characters would > hit against other (esthetical) boundaries first. > > We currently allocate 50 dev_t's at compile time (to be able to > make it until malloc(9) works) and the rest with malloc(9). The > current size of a dev_t is 140 bytes + space for the name, so in > theory we can allow for 116 bytes long names at a net cost of only > 50 times the increase since malloc(9) already allocates us 256 bytes > buckets, so the net cost of this change was 2400 bytes. > > Summary: I'm shelving the unlimited name length for now, hoping that > 63 or subsequently 116 will be enough to cater for our needs. > > Poul-Henning > > > In message <200302041107.h14B7ST1060100@repoman.freebsd.org>, Poul-Henning Kamp > writes: > >phk 2003/02/04 03:07:28 PST > > > > Modified files: > > sys/sys param.h > > Log: > > Increase the allowed length of device names to 63 characters. > > > > This is a band-aid while I fret over how much breakage removing the > > restriction entirely will result in. > > > > Please note that this is still a limit for the entire pathname > > relative to the mountpoint of devfs, so the length of "/dev/fd/3" > > is 4 characters. > > > > Revision Changes Path > > 1.142 +1 -1 src/sys/sys/param.h > > > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 20:10:40 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1223F37B401 for ; Tue, 4 Feb 2003 20:10:37 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AB4443F43 for ; Tue, 4 Feb 2003 20:10:36 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 5BCFC536E; Wed, 5 Feb 2003 05:10:34 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: New kernel allocation API From: Dag-Erling Smorgrav Date: Wed, 05 Feb 2003 05:10:33 +0100 Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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 --=-=-= The attached patch creates two new entry points for malloc(), named kalloc() and kalloc_nowait(), eliminating the need for the M_NOWAIT and M_TRYWAIT constants. The patch also defines malloc() as a macro which invokes the appropriate API function, so source-level compatibility is maintained. DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=kalloc.diff Index: sys/sys/malloc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/malloc.h,v retrieving revision 1.69 diff -u -r1.69 malloc.h --- sys/sys/malloc.h 21 Jan 2003 08:56:14 -0000 1.69 +++ sys/sys/malloc.h 5 Feb 2003 04:05:14 -0000 @@ -107,7 +107,8 @@ unsigned long low, unsigned long high, unsigned long alignment, unsigned long boundary); void free(void *addr, struct malloc_type *type); -void *malloc(unsigned long size, struct malloc_type *type, int flags); +void *kalloc(size_t n, struct malloc_type *t, int z, struct mtx *m); +void *kalloc_nowait(size_t n, struct malloc_type *t, int z); void malloc_init(void *); int malloc_last_fail(void); void malloc_uninit(void *); @@ -115,6 +116,13 @@ int flags); void *reallocf(void *addr, unsigned long size, struct malloc_type *type, int flags); +/* + * Legacy API. + */ +#define malloc(sz, mt, fl) (((fl) & M_NOWAIT) ? \ + kalloc_nowait((sz), (mt), ((fl) & M_ZERO)) : \ + kalloc((sz), (mt), ((fl) & M_ZERO), NULL)) + #endif /* _KERNEL */ #endif /* !_SYS_MALLOC_H_ */ Index: sys/kern/kern_malloc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.115 diff -u -r1.115 kern_malloc.c --- sys/kern/kern_malloc.c 1 Feb 2003 10:07:49 -0000 1.115 +++ sys/kern/kern_malloc.c 5 Feb 2003 04:09:05 -0000 @@ -153,6 +153,9 @@ * If M_NOWAIT is set, this routine will not block and return NULL if * the allocation fails. */ +#ifdef malloc +#undef malloc +#endif void * malloc(size, type, flags) unsigned long size; @@ -216,6 +219,43 @@ } #endif return ((void *) va); +} + +/* + * Allocates size bytes, blocking if the request can't be satisfied right + * away. If mtx is non-NULL it may be released during kalloc(), and will + * be re-acquired before returning. If zero is non-zero, the allocated + * memory is cleared before kalloc() returns. + */ +void * +kalloc(size_t size, struct malloc_type *type, int zero, struct mtx *mtx) +{ + int flags; + void *va; + + KASSERT(curthread->td_intr_nesting_level == 0, + ("kalloc() called in interrupt context")); + flags = zero ? 0 : M_ZERO; + mtx_unlock(mtx); + va = malloc(size, type, flags); + mtx_lock(mtx); + return (va); +} + +/* + * Attempts to allocate size bytes, and returns NULL if the request can't + * be satisfied right away. If zero is non-zero, the allocated memory is + * cleared before kalloc_nowait() returns. + */ +void * +kalloc_nowait(size_t size, struct malloc_type *type, int zero) +{ + int flags; + void *va; + + flags = M_NOWAIT | (zero ? 0 : M_ZERO); + va = malloc(size, type, flags); + return (va); } /* --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 20:14:48 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1649C37B401 for ; Tue, 4 Feb 2003 20:14:45 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3D7143F3F for ; Tue, 4 Feb 2003 20:14:43 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id B22D7536E; Wed, 5 Feb 2003 05:14:41 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: Re: New kernel allocation API From: Dag-Erling Smorgrav Date: Wed, 05 Feb 2003 05:14:40 +0100 In-Reply-To: (Dag-Erling Smorgrav's message of "Wed, 05 Feb 2003 05:10:33 +0100") Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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 --=-=-= A slight amendment is necessary to eliminate warnings. Here's the new patch. DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=kalloc.diff Index: sys/sys/malloc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/malloc.h,v retrieving revision 1.69 diff -u -r1.69 malloc.h --- sys/sys/malloc.h 21 Jan 2003 08:56:14 -0000 1.69 +++ sys/sys/malloc.h 5 Feb 2003 04:05:14 -0000 @@ -107,7 +107,8 @@ unsigned long low, unsigned long high, unsigned long alignment, unsigned long boundary); void free(void *addr, struct malloc_type *type); -void *malloc(unsigned long size, struct malloc_type *type, int flags); +void *kalloc(size_t n, struct malloc_type *t, int z, struct mtx *m); +void *kalloc_nowait(size_t n, struct malloc_type *t, int z); void malloc_init(void *); int malloc_last_fail(void); void malloc_uninit(void *); @@ -115,6 +116,13 @@ int flags); void *reallocf(void *addr, unsigned long size, struct malloc_type *type, int flags); +/* + * Legacy API. + */ +#define malloc(sz, mt, fl) (((fl) & M_NOWAIT) ? \ + kalloc_nowait((sz), (mt), ((fl) & M_ZERO)) : \ + kalloc((sz), (mt), ((fl) & M_ZERO), NULL)) + #endif /* _KERNEL */ #endif /* !_SYS_MALLOC_H_ */ Index: sys/kern/kern_malloc.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v retrieving revision 1.115 diff -u -r1.115 kern_malloc.c --- sys/kern/kern_malloc.c 1 Feb 2003 10:07:49 -0000 1.115 +++ sys/kern/kern_malloc.c 5 Feb 2003 04:13:12 -0000 @@ -153,11 +153,12 @@ * If M_NOWAIT is set, this routine will not block and return NULL if * the allocation fails. */ +#ifdef malloc +#undef malloc +void *malloc(unsigned long size, struct malloc_type *type, int flags); +#endif void * -malloc(size, type, flags) - unsigned long size; - struct malloc_type *type; - int flags; +malloc(unsigned long size, struct malloc_type *type, int flags) { int indx; caddr_t va; @@ -216,6 +217,43 @@ } #endif return ((void *) va); +} + +/* + * Allocates size bytes, blocking if the request can't be satisfied right + * away. If mtx is non-NULL it may be released during kalloc(), and will + * be re-acquired before returning. If zero is non-zero, the allocated + * memory is cleared before kalloc() returns. + */ +void * +kalloc(size_t size, struct malloc_type *type, int zero, struct mtx *mtx) +{ + int flags; + void *va; + + KASSERT(curthread->td_intr_nesting_level == 0, + ("kalloc() called in interrupt context")); + flags = zero ? 0 : M_ZERO; + mtx_unlock(mtx); + va = malloc(size, type, flags); + mtx_lock(mtx); + return (va); +} + +/* + * Attempts to allocate size bytes, and returns NULL if the request can't + * be satisfied right away. If zero is non-zero, the allocated memory is + * cleared before kalloc_nowait() returns. + */ +void * +kalloc_nowait(size_t size, struct malloc_type *type, int zero) +{ + int flags; + void *va; + + flags = M_NOWAIT | (zero ? 0 : M_ZERO); + va = malloc(size, type, flags); + return (va); } /* --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Feb 4 20:30:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7100337B405 for ; Tue, 4 Feb 2003 20:30:24 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D0C643F79 for ; Tue, 4 Feb 2003 20:30:24 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 06D122A8C1; Tue, 4 Feb 2003 20:30:24 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Dag-Erling Smorgrav Cc: arch@freebsd.org Subject: Re: New kernel allocation API In-Reply-To: Date: Tue, 04 Feb 2003 20:30:24 -0800 From: Peter Wemm Message-Id: <20030205043024.06D122A8C1@canning.wemm.org> 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 Dag-Erling Smorgrav wrote: > --=-=-= > > The attached patch creates two new entry points for malloc(), named > kalloc() and kalloc_nowait(), eliminating the need for the M_NOWAIT > and M_TRYWAIT constants. The patch also defines malloc() as a macro > which invokes the appropriate API function, so source-level > compatibility is maintained. The current bikeshed is about the mbuf functions as well, not just the malloc function.. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 0:50:29 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E58337B401 for ; Wed, 5 Feb 2003 00:50:28 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6740943FC1 for ; Wed, 5 Feb 2003 00:50:27 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h158oKv34760; Wed, 5 Feb 2003 03:50:20 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 5 Feb 2003 03:50:20 -0500 (EST) From: Jeff Roberson To: Peter Wemm Cc: Dag-Erling Smorgrav , Subject: Re: New kernel allocation API In-Reply-To: <20030205043024.06D122A8C1@canning.wemm.org> Message-ID: <20030205034836.L96521-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Tue, 4 Feb 2003, Peter Wemm wrote: > Dag-Erling Smorgrav wrote: > > --=-=-= > > > > The attached patch creates two new entry points for malloc(), named > > kalloc() and kalloc_nowait(), eliminating the need for the M_NOWAIT > > and M_TRYWAIT constants. The patch also defines malloc() as a macro > > which invokes the appropriate API function, so source-level > > compatibility is maintained. > > The current bikeshed is about the mbuf functions as well, not just the > malloc function.. > If you would like to make a new malloc/free api I have some comments. most notably, free should require the size on return. This yields much cleaner implementations with little or no cost to most consumers. I had some local patches to do this when I was working on uma but not having naturally aligned sizes broke too much code. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 3:15:27 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC1D37B401 for ; Wed, 5 Feb 2003 03:15:26 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B64843F3F for ; Wed, 5 Feb 2003 03:15:25 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 4FBBF536E; Wed, 5 Feb 2003 12:15:21 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: David Schultz Cc: arch@freebsd.org Subject: Re: New kernel allocation API From: Dag-Erling Smorgrav Date: Wed, 05 Feb 2003 12:15:21 +0100 In-Reply-To: <20030205045103.GB2168@HAL9000.homeunix.com> (David Schultz's message of "Tue, 4 Feb 2003 20:51:03 -0800") Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) References: <20030205045103.GB2168@HAL9000.homeunix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 David Schultz writes: > BTW, it looks like the KASSERT in kalloc() eliminates the need for > the one in malloc(). Furthermore, there's another KASSERT in > malloc() that could be moved to kalloc(). I know. AT this stage, all the patch does is define the new API and implement it in terms of the old one. I duplicated the KASSERT so I could tailor the panic string to the new API. Note that since malloc() still exists and is not static, the patch maintains binary compatibility (e.g. with modules compiled before the patch was applied). It would therefore have been wrong to modify the behaviour of malloc(). DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 5:18:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 935D437B40E for ; Wed, 5 Feb 2003 05:18:47 -0800 (PST) Received: from mail.iinet.net.au (mail-02.iinet.net.au [203.59.3.34]) by mx1.FreeBSD.org (Postfix) with SMTP id C8AF243FB1 for ; Wed, 5 Feb 2003 05:18:45 -0800 (PST) (envelope-from riggs@mugiri-in-au.dyndns.tv) Received: (qmail 13759 invoked from network); 5 Feb 2003 13:18:34 -0000 Received: from unknown (HELO theDude.MuGiRi.au) (203.59.112.126) by mail.iinet.net.au with SMTP; 5 Feb 2003 13:18:34 -0000 Received: from trillian.mugiri.au (trillian.MuGiRi.au [10.0.0.101]) by theDude.MuGiRi.au (8.12.6/8.12.6) with ESMTP id h15DIb5H028835; Wed, 5 Feb 2003 21:18:37 +0800 (WST) (envelope-from riggs@mugiri-in-au.dyndns.tv) Received: from trillian.mugiri.au (localhost [127.0.0.1]) by trillian.mugiri.au (8.12.6/8.12.6) with ESMTP id h15DIZk8001133; Wed, 5 Feb 2003 21:18:35 +0800 (WST) (envelope-from riggs@trillian.mugiri.au) Received: (from riggs@localhost) by trillian.mugiri.au (8.12.6/8.12.6/Submit) id h15DIXEq001132; Wed, 5 Feb 2003 21:18:33 +0800 (WST) (envelope-from riggs) Date: Wed, 5 Feb 2003 21:18:32 +0800 From: "Thomas E. Zander" To: Mikhail Teterin Cc: arch@FreeBSD.org, Alfred Perlstein , Wes Peters , Mario Sergio Fujikawa Ferreira , "Thomas E. Zander" Subject: Re: dlclose() vs. atexit() Message-ID: <20030205131832.GF897@trillian.mugiri.au> References: <200302030506.h1356Nha011918@repoman.freebsd.org> <1044319099.358.57.camel@zaphod.softweyr.com> <20030204082625.GB85104@elvis.mu.org> <200302041639.h14GcxCi010108@nce2.hadiko.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <200302041639.h14GcxCi010108@nce2.hadiko.de> Organization: RiggiServ - Ihr Partner =?iso-8859-15?Q?f?= =?iso-8859-15?Q?=FCr?= alles Delikate X-PGP-KeyID: 0xC85996CD X-PGP-Fingerprint: 4F59 75B4 4CE3 3B00 BC61 5400 8DD4 8929 C859 96CD X-Mailer: Riggisoft Ausguck Eggsbress (Build 1044448110) X-Operating-System: Riggiland BSD 5.0-RELEASE (To serve and protect.) 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 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Well, Am Tue, dem 04. Feb 2003, um 10:46 -0500 Uhr schrubte Mikhail Teterin zum Thema [dlclose() vs. atexit()]: > Linux [...] 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/L= inux > Loading the libraries > ./l0.so loaded as 0x8049ad0 > ./l1.so loaded as 0x8049e00 > Library 0 calling atexit(0x40016788) > Library 1 calling atexit(0x40014788) > Unloading the libraries > Exit handler 0x40016788 of library 1 is invoked > 0x8049ad0 unloaded > Segmentation fault (core dumped) *this* is really surprising me. I mean, most of the mplayer developers work under linux. And nobody of them takes care about this for...yea...years now?! It seems that this won't be a 5-minute patch to get it to work really cleanly... Riggs --=20 - Die Welt schl=E4ft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit | ------------------------- -- --- Denn per Infrarot seh ich | just to fit your --- ---- Die Nacht ist wirklich widerlich. | primitive screen. ---- --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQE+QQ8ojdSJKchZls0RAm8YAJ0RENURxRlbC765Nrwjyse36mYpQgCdFjFi Zn6bQwq0B2a0gGt3HFMu7X8= =gqrh -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 5:25: 2 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC77037B42F for ; Wed, 5 Feb 2003 05:25:00 -0800 (PST) Received: from mail.iinet.net.au (mail-04.iinet.net.au [203.59.3.36]) by mx1.FreeBSD.org (Postfix) with SMTP id E33D343FBD for ; Wed, 5 Feb 2003 05:24:57 -0800 (PST) (envelope-from riggs@mugiri-in-au.dyndns.tv) Received: (qmail 2502 invoked from network); 5 Feb 2003 13:21:40 -0000 Received: from unknown (HELO theDude.MuGiRi.au) (203.59.112.126) by mail.iinet.net.au with SMTP; 5 Feb 2003 13:21:40 -0000 Received: from trillian.mugiri.au (trillian.MuGiRi.au [10.0.0.101]) by theDude.MuGiRi.au (8.12.6/8.12.6) with ESMTP id h15DLi5H028879; Wed, 5 Feb 2003 21:21:45 +0800 (WST) (envelope-from riggs@mugiri-in-au.dyndns.tv) Received: from trillian.mugiri.au (localhost [127.0.0.1]) by trillian.mugiri.au (8.12.6/8.12.6) with ESMTP id h15DLik8001162; Wed, 5 Feb 2003 21:21:44 +0800 (WST) (envelope-from riggs@trillian.mugiri.au) Received: (from riggs@localhost) by trillian.mugiri.au (8.12.6/8.12.6/Submit) id h15DLh13001161; Wed, 5 Feb 2003 21:21:43 +0800 (WST) (envelope-from riggs) Date: Wed, 5 Feb 2003 21:21:42 +0800 From: "Thomas E. Zander" To: Mikhail Teterin Cc: arch@FreeBSD.org, Alfred Perlstein , Wes Peters , Mario Sergio Fujikawa Ferreira Subject: Re: dlclose() vs. atexit() Message-ID: <20030205132142.GG897@trillian.mugiri.au> References: <200302030506.h1356Nha011918@repoman.freebsd.org> <1044319099.358.57.camel@zaphod.softweyr.com> <20030204082625.GB85104@elvis.mu.org> <200302041639.h14GcxCi010108@nce2.hadiko.de> <20030205131832.GF897@trillian.mugiri.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: <20030205131832.GF897@trillian.mugiri.au> Organization: RiggiServ - Ihr Partner =?iso-8859-15?Q?f?= =?iso-8859-15?Q?=FCr?= alles Delikate X-PGP-KeyID: 0xC85996CD X-PGP-Fingerprint: 4F59 75B4 4CE3 3B00 BC61 5400 8DD4 8929 C859 96CD X-Mailer: Riggisoft Ausguck Eggsbress (Build 1044448110) X-Operating-System: Riggiland BSD 5.0-RELEASE (To serve and protect.) 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 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Oh, sorry...I've made a little mistake.. please do *not* use this riggs@trillian.mugiri.au email address, since it is localnetwork-not-reachable-from-outer-world stuff. Thanks Riggs --=20 - Die Welt schl=E4ft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit | ------------------------- -- --- Denn per Infrarot seh ich | just to fit your --- ---- Die Nacht ist wirklich widerlich. | primitive screen. ---- --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQE+QQ/mjdSJKchZls0RAkUyAJ48kYTKYf8I5BS9epACEJDpvwSCZwCfS1G0 AUFfeUt11CKWT27Lv7Lr3Z0= =7xrJ -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 5:45:11 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0771B37B401 for ; Wed, 5 Feb 2003 05:45:10 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2781E43F75 for ; Wed, 5 Feb 2003 05:45:09 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h15Dj8mI000600; Wed, 5 Feb 2003 05:45:08 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h15Dj8AA000599; Wed, 5 Feb 2003 05:45:08 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 5 Feb 2003 05:45:08 -0800 From: David Schultz To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030205134508.GA520@HAL9000.homeunix.com> Mail-Followup-To: Dag-Erling Smorgrav , arch@FreeBSD.ORG References: <20030205045103.GB2168@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thus spake Dag-Erling Smorgrav : > David Schultz writes: > > BTW, it looks like the KASSERT in kalloc() eliminates the need for > > the one in malloc(). Furthermore, there's another KASSERT in > > malloc() that could be moved to kalloc(). > > I know. AT this stage, all the patch does is define the new API and > implement it in terms of the old one. I duplicated the KASSERT so I > could tailor the panic string to the new API. > > Note that since malloc() still exists and is not static, the patch > maintains binary compatibility (e.g. with modules compiled before the > patch was applied). It would therefore have been wrong to modify the > behaviour of malloc(). The check is conditional on INVARIANTS, and any module that can trigger the panic is broken and therefore incompatible with any valid ABI anyway. But I don't mean to nitpick; I thought I'd just point out the redundancy privately in case it was unintended. I would really like to see *any* reasonable fix for the malloc flags mess actually get committed, and your design certainly qualifies. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 6:55:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F55D37B401 for ; Wed, 5 Feb 2003 06:55:49 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 642DC43FA7 for ; Wed, 5 Feb 2003 06:55:48 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h15EtkYu040416; Wed, 5 Feb 2003 15:55:46 +0100 (CET) (envelope-from phk@freebsd.org) To: Dag-Erling Smorgrav Cc: David Schultz , arch@freebsd.org Subject: Re: New kernel allocation API From: phk@freebsd.org In-Reply-To: Your message of "Wed, 05 Feb 2003 12:15:21 +0100." Date: Wed, 05 Feb 2003 15:55:46 +0100 Message-ID: <40415.1044456946@critter.freebsd.dk> 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 In message , Dag-Erling Smorgrav writes: >David Schultz writes: >> BTW, it looks like the KASSERT in kalloc() eliminates the need for >> the one in malloc(). Furthermore, there's another KASSERT in >> malloc() that could be moved to kalloc(). > >I know. AT this stage, all the patch does is define the new API and >implement it in terms of the old one. I duplicated the KASSERT so I >could tailor the panic string to the new API. If we are going to implement a new kernel allocator API, there are a host of issues we should consider, Jeff already mentioned one of them, passing size to ::free, and we must also design the API so that we can implement debugging and correctness checks in an efficient and usable manner. Considering the problems our kernel suffers from at the moment, inventing a new memory allocation API is not even on the top 50 list of things we need to do. So can we just shelve this proposal until we have time and need for it and until we know (even) more about the needs of our SMPng kernel ? Thanks in advance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 10:43:43 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BAEDE37B401 for ; Wed, 5 Feb 2003 10:43:41 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5686043F3F for ; Wed, 5 Feb 2003 10:43:41 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc53.attbi.com (rwcrmhc53) with ESMTP id <20030205184340053003l60ke>; Wed, 5 Feb 2003 18:43:40 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA97152; Wed, 5 Feb 2003 10:43:39 -0800 (PST) Date: Wed, 5 Feb 2003 10:43:38 -0800 (PST) From: Julian Elischer To: Jeff Roberson Cc: Peter Wemm , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: New kernel allocation API In-Reply-To: <20030205034836.L96521-100000@mail.chesapeake.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 5 Feb 2003, Jeff Roberson wrote: > On Tue, 4 Feb 2003, Peter Wemm wrote: > > > Dag-Erling Smorgrav wrote: > > > --=-=-= > > > > > > The attached patch creates two new entry points for malloc(), named > > > kalloc() and kalloc_nowait(), eliminating the need for the M_NOWAIT > > > and M_TRYWAIT constants. The patch also defines malloc() as a macro > > > which invokes the appropriate API function, so source-level > > > compatibility is maintained. > > > > The current bikeshed is about the mbuf functions as well, not just the > > malloc function.. > > > > If you would like to make a new malloc/free api I have some comments. > most notably, free should require the size on return. This yields much > cleaner implementations with little or no cost to most consumers. I had > some local patches to do this when I was working on uma but not having > naturally aligned sizes broke too much code. I know several consumers where the size is not known or would be expensive to calculate on free. > > Cheers, > Jeff > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 10:49:21 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C671637B405 for ; Wed, 5 Feb 2003 10:49:20 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EE3943F43 for ; Wed, 5 Feb 2003 10:49:20 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0205.cvx21-bradley.dialup.earthlink.net ([209.179.192.205] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18gUbl-0001AM-00; Wed, 05 Feb 2003 10:49:18 -0800 Message-ID: <3E415C5A.4315EBD3@mindspring.com> Date: Wed, 05 Feb 2003 10:47:54 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: David Schultz , arch@freebsd.org Subject: Re: New kernel allocation API References: <20030205045103.GB2168@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a48096dd0585617a13d0a309608cd2ff66350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Dag-Erling Smorgrav wrote: > David Schultz writes: > > BTW, it looks like the KASSERT in kalloc() eliminates the need for > > the one in malloc(). Furthermore, there's another KASSERT in > > malloc() that could be moved to kalloc(). > > I know. AT this stage, all the patch does is define the new API and > implement it in terms of the old one. I duplicated the KASSERT so I > could tailor the panic string to the new API. This good work is incredibly necessary, to clear up the SMP mess, going forward. It's invaluable. Thanks, DES! -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 10:58:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B5DE37B401; Wed, 5 Feb 2003 10:58:23 -0800 (PST) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BA4B43F43; Wed, 5 Feb 2003 10:58:22 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0205.cvx21-bradley.dialup.earthlink.net ([209.179.192.205] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18gUkX-0002GI-00; Wed, 05 Feb 2003 10:58:22 -0800 Message-ID: <3E415E7B.25C1D42@mindspring.com> Date: Wed, 05 Feb 2003 10:56:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: phk@freebsd.org Cc: Dag-Erling Smorgrav , David Schultz , arch@freebsd.org Subject: Re: New kernel allocation API References: <40415.1044456946@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a435b63c88da451e6dfc662e062ebe0d55350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 phk@freebsd.org wrote: > If we are going to implement a new kernel allocator API, there are > a host of issues we should consider, Jeff already mentioned one of > them, passing size to ::free, and we must also design the API so that > we can implement debugging and correctness checks in an efficient > and usable manner. For someone who uses C++ scope identification in the listing of the function name "free", your support of knowing the size of the object being freed is mystifying. If the size of the object is passed in to the free function, it means that it can't be freed by a function which destructs a superclass. E.g.: struct superclass { ... }; struct class1 { /* 1024 bytes */ struct superclass c1_sc; ... }; struct class2 { /* 512 bytes */ struct superclass c2_sc; ... } struct superclass * zifmeac1() { struct class1 *c1p; c2p = malloc(sizeof *c1p); ... return((struct superclass *)c1p); } struct superclass * zifmeac2() { struct class2 *c2p; c2p = malloc(sizeof *c2p); ... return((struct superclass *)c2p); } main() { struct superclass *sc; ... if( condition) sc = zifmeac1(); else sc = zifmeac2(); ... free( sc); } > Considering the problems our kernel suffers from at the moment, > inventing a new memory allocation API is not even on the top 50 > list of things we need to do. > > So can we just shelve this proposal until we have time and need for > it and until we know (even) more about the needs of our SMPng kernel ? You mean like "the ability to deprecate blocking allocations incrementally, by changing which API is used"? That's what DES's patch provides. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 11:26:41 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9EBC37B438 for ; Wed, 5 Feb 2003 11:26:39 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D7543F93 for ; Wed, 5 Feb 2003 11:26:37 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id B9AC25371; Wed, 5 Feb 2003 20:26:34 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Julian Elischer Cc: Jeff Roberson , Peter Wemm , arch@FreeBSD.ORG Subject: Re: New kernel allocation API From: Dag-Erling Smorgrav Date: Wed, 05 Feb 2003 20:26:34 +0100 In-Reply-To: (Julian Elischer's message of "Wed, 5 Feb 2003 10:43:38 -0800 (PST)") Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Julian Elischer writes: > I know several consumers where the size is not known or would be > expensive to calculate on free. Well then, void kfree(void *va, size_t size, struct malloc_type *type); void kfree_nosize(void *va, struct malloc_type *type); where the former checks that the size is correct, while the latter doesn't. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 12:12:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 676D837B401 for ; Wed, 5 Feb 2003 12:12:48 -0800 (PST) Received: from unox.bitpit.net (t-23-57.athome.tue.nl [131.155.227.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD2643FAF for ; Wed, 5 Feb 2003 12:12:42 -0800 (PST) (envelope-from marijn@bitpit.net) Received: from hoop.bitpit.net (unknown [192.168.1.2]) by unox.bitpit.net (Postfix) with ESMTP id 3D30F4B1 for ; Wed, 5 Feb 2003 21:12:35 +0100 (CET) Received: from hoop.bitpit.net (localhost [127.0.0.1]) by hoop.bitpit.net (8.12.6/8.12.6) with ESMTP id h15KCbeZ001111 for ; Wed, 5 Feb 2003 21:12:38 +0100 (CET) (envelope-from marijn@hoop.bitpit.net) Received: (from marijn@localhost) by hoop.bitpit.net (8.12.6/8.12.6/Submit) id h15KCbOC001110 for arch@freebsd.org; Wed, 5 Feb 2003 21:12:37 +0100 (CET) Date: Wed, 5 Feb 2003 21:12:36 +0100 From: Marijn Meijles To: arch@freebsd.org Subject: New scheduler problem Message-ID: <20030205201236.GA918@hoop.bitpit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i 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 Hi, I just tried the new scheduler (yesterdays cvsup), but it gives horrible interactve performance in some situations. Especially with mixed interactive and non-interactive applications like mozilla. This is perfectly understandable. Suppose I have a fair number of non-interactive apps running which generate load (make -j4). moz needs about 20% cpu time on my box (P3-550 UP) when it sits idle because of animated gifs. On an idle box, moz sleeps enough to return its priority to the standard level after rendering a page, but on a loaded box it stays a non-interactive app. PRI jumps to 120 and stays there because mozilla doesn't get a chance to sleep enough to lower PRI. With 4 other non-interactive apps combined with interactive apps, moz becomes quite unusable. If I kill the make, moz' PRI gradually drops back to the standard level. Lowering the decay rate in sched_slice helps, but that's not a real solution. Any ideas? -- Marijn@bitpit.net --- This message is ROT-52 encoded. Reading it will violate the DMCA. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 12:15:41 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5EA237B401 for ; Wed, 5 Feb 2003 12:15:39 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 691D743E4A for ; Wed, 5 Feb 2003 12:15:39 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 4409C2A89E; Wed, 5 Feb 2003 12:15:34 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: Jeff Roberson , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: New kernel allocation API In-Reply-To: Date: Wed, 05 Feb 2003 12:15:34 -0800 From: Peter Wemm Message-Id: <20030205201534.4409C2A89E@canning.wemm.org> 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 Julian Elischer wrote: > > > On Wed, 5 Feb 2003, Jeff Roberson wrote: > > > On Tue, 4 Feb 2003, Peter Wemm wrote: > > > > > Dag-Erling Smorgrav wrote: > > > > --=-=-= > > > > > > > > The attached patch creates two new entry points for malloc(), named > > > > kalloc() and kalloc_nowait(), eliminating the need for the M_NOWAIT > > > > and M_TRYWAIT constants. The patch also defines malloc() as a macro > > > > which invokes the appropriate API function, so source-level > > > > compatibility is maintained. > > > > > > The current bikeshed is about the mbuf functions as well, not just the > > > malloc function.. > > > > > > > If you would like to make a new malloc/free api I have some comments. > > most notably, free should require the size on return. This yields much > > cleaner implementations with little or no cost to most consumers. I had > > some local patches to do this when I was working on uma but not having > > naturally aligned sizes broke too much code. > > I know several consumers where the size is not known or would be > expensive to calculate on free. When I've had to do this in the (distant) past, I've stored the variable size information inside the fixed portion of the structure that was being allocated.. In other situations situations, I used a second size field next to where I stored the pointer. This wasn't a great burden. Nostalgia note: Anybody remember AllocMem() and FreeMem()? Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 12:34:38 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C00237B406 for ; Wed, 5 Feb 2003 12:34:37 -0800 (PST) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96BBB43F75 for ; Wed, 5 Feb 2003 12:34:34 -0800 (PST) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (12-232-168-4.client.attbi.com[12.232.168.4]) by rwcrmhc51.attbi.com (rwcrmhc51) with ESMTP id <2003020520343305100hrv4he>; Wed, 5 Feb 2003 20:34:33 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA98338; Wed, 5 Feb 2003 12:34:33 -0800 (PST) Date: Wed, 5 Feb 2003 12:34:32 -0800 (PST) From: Julian Elischer To: Peter Wemm Cc: Jeff Roberson , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: New kernel allocation API In-Reply-To: <20030205201534.4409C2A89E@canning.wemm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 5 Feb 2003, Peter Wemm wrote: > Julian Elischer wrote: > > > When I've had to do this in the (distant) past, I've stored the variable > size information inside the fixed portion of the structure that was being > allocated.. In other situations situations, I used a second size field > next to where I stored the pointer. This wasn't a great burden. > > Nostalgia note: Anybody remember AllocMem() and FreeMem()? I know it's not a great burdon if you are writing the code. It might be a bigger burdon if you are just working with code you don't fully understand, or don't have full access to. I added (many years ago) enough info to the external mbuf info so that it could cope with this (I don't know if it still does but I did have a field for "allocated buffer size"). > > Cheers, > -Peter > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com > "All of this is for nothing if we don't go to the stars" - JMS/B5 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 12:54:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBBAA37B40B for ; Wed, 5 Feb 2003 12:54:40 -0800 (PST) Received: from yahoo.com.tw (135.0.30.61.isp.tfn.net.tw [61.30.0.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7172D43F75 for ; Wed, 5 Feb 2003 12:54:39 -0800 (PST) (envelope-from conychangkimo@yahoo.com.tw) From: jerry@FreeBSD.ORG To: µ¹»{¯u¥´«÷ªºªB¤Í@FreeBSD.ORG Subject: ¸gÀ礧¯«ªº¯µ±K Reply-To: conychangkimo@yahoo.com.tw Date: 06 Feb 2003 05:14:37 +0800 Organization: Foobar Inc. X-Mailer: Gammadyne Mailer x-delete-me: 1 (this tells Gammadyne's server to delete the message) MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: <20030205205439.7172D43F75@mx1.FreeBSD.org> 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 ¦L¶r¾÷

·s¦~§ª«°e±z¤@¥x¦L¶r¾÷ ...

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 13:19:14 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E8F037B401 for ; Wed, 5 Feb 2003 13:19:13 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8093643F79 for ; Wed, 5 Feb 2003 13:18:57 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 4908E2A89E; Wed, 5 Feb 2003 13:18:57 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Julian Elischer Cc: Jeff Roberson , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: New kernel allocation API In-Reply-To: Date: Wed, 05 Feb 2003 13:18:57 -0800 From: Peter Wemm Message-Id: <20030205211857.4908E2A89E@canning.wemm.org> 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 Julian Elischer wrote: > > > On Wed, 5 Feb 2003, Peter Wemm wrote: > > > Julian Elischer wrote: > > > > > When I've had to do this in the (distant) past, I've stored the variable > > size information inside the fixed portion of the structure that was being > > allocated.. In other situations situations, I used a second size field > > next to where I stored the pointer. This wasn't a great burden. > > > > Nostalgia note: Anybody remember AllocMem() and FreeMem()? > > I know it's not a great burdon if you are writing the code. > It might be a bigger burdon if you are just working with code you > don't fully understand, or don't have full access to. Quite correct. My choice of wording was poor. I was trying to get across the point that when you know what the rules are and all the rest of the code does it the same, it isn't a big deal to do. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Feb 5 22:38: 4 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 486CF37B40E for ; Wed, 5 Feb 2003 22:37:58 -0800 (PST) Received: from rockshows.com.br (200191011144-dial-user-BOL.acessonet.com.br [200.191.11.144]) by mx1.FreeBSD.org (Postfix) with SMTP id 5A00943FEC for ; Wed, 5 Feb 2003 22:37:31 -0800 (PST) (envelope-from fatorcincoo@rockshows.com.br) From: "Banda Fator Cinco" To: Subject: Dê uma Força ao Nosso Rock Nacional Mime-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Date: Thu, 6 Feb 2003 04:38:24 -0200 Content-Transfer-Encoding: 8bit Message-Id: <20030206063731.5A00943FEC@mx1.FreeBSD.org> 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

Banda Fator Cinco
 
Pedimos a você que esta recebendo este e-mail para dar uma força ao nosso rock nacional, a banda Fator Cinco teve uma de suas musicas veiculada na 89 FM (A Rádio Rock) e na KISS FM não custa nada a gente pedir a música de novo e quem sabe ela poder entrar na programação destas rádio. Vamos lá pessoal !!!
 
A música chama-se 11 DE SETEMBRO e para pedi-la na 89FM mande um e-mail para avezdobrasil@89fm.com.br ou ligue para 252-6543 e para pedir na KISS FM mande um e-mail para kissfm@kissfm.com.br .  
 
Vamos pedir a música novamente para fazer a Fator Cinco entrar na programação destas rádios, contamos com sua ajuda . VALEU !!!
 
Você pode ouvir o trecho desta música e conhecer melhor a banda Fator Cinco acessando:
 
Um grande abraço da família Fator Cinco
 
INFORMATIVO
 
 

 Caso não queira mais receber nossos informativos Click aqui

 

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 6 1: 2:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36F8637B401 for ; Thu, 6 Feb 2003 01:02:29 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6562E43F3F for ; Thu, 6 Feb 2003 01:02:28 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h16928m13858; Thu, 6 Feb 2003 04:02:09 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Thu, 6 Feb 2003 04:02:08 -0500 (EST) From: Jeff Roberson To: Julian Elischer Cc: Peter Wemm , Dag-Erling Smorgrav , Subject: Re: New kernel allocation API In-Reply-To: Message-ID: <20030206040110.V79483-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 5 Feb 2003, Julian Elischer wrote: > > I know several consumers where the size is not known or would be > expensive to calculate on free. > I bet there are 10x as many that do: foo = malloc(sizeof(*foo)); Which could just as easily do: free(foo, sizeof(*foo)); Optimize for the common case. It will make the allocator MUCH faster. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 6 1:40:49 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A6BD37B401 for ; Thu, 6 Feb 2003 01:40:48 -0800 (PST) Received: from MX2.estpak.ee (ld1.estpak.ee [194.126.101.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 298A443F3F for ; Thu, 6 Feb 2003 01:40:47 -0800 (PST) (envelope-from kalts@estpak.ee) Received: from kevad.internal (80-235-38-93-dsl.mus.estpak.ee [80.235.38.93]) by MX2.estpak.ee (Postfix) with ESMTP id 260F173938; Thu, 6 Feb 2003 11:39:29 +0200 (EET) Received: from kevad.internal (localhost [127.0.0.1]) by kevad.internal (8.12.6/8.12.6) with ESMTP id h169egQO002084; Thu, 6 Feb 2003 11:40:42 +0200 (EET) (envelope-from vallo@kevad.internal) Received: (from vallo@localhost) by kevad.internal (8.12.6/8.12.6/Submit) id h169efSQ002083; Thu, 6 Feb 2003 11:40:41 +0200 (EET) (envelope-from vallo) Date: Thu, 6 Feb 2003 11:40:40 +0200 From: Vallo Kallaste To: Marijn Meijles Cc: arch@freebsd.org Subject: Re: New scheduler problem Message-ID: <20030206094040.GA2000@kevad.internal> Reply-To: kalts@estpak.ee References: <20030205201236.GA918@hoop.bitpit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030205201236.GA918@hoop.bitpit.net> User-Agent: Mutt/1.5.1i-ja.1 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 On Wed, Feb 05, 2003 at 09:12:36PM +0100, Marijn Meijles wrote: > I just tried the new scheduler (yesterdays cvsup), but it gives horrible > interactve performance in some situations. Especially with mixed interactive > and non-interactive applications like mozilla. This is perfectly Running two seti@home processes (2 CPU's) at nice 19 kills interactive peformance entirely. Worse than 300baud modem on the console, mouse will not work at all. SCHED_4BSD is fine. -- Vallo Kallaste kalts@estpak.ee To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 6 8:58:30 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A553E37B405 for ; Thu, 6 Feb 2003 08:58:25 -0800 (PST) Received: from aol.com (adsl-66-124-9-157.dsl.lsan03.pacbell.net [66.124.9.157]) by mx1.FreeBSD.org (Postfix) with SMTP id ADD1843F3F for ; Thu, 6 Feb 2003 08:58:24 -0800 (PST) (envelope-from GlobeStrat5824@aol.com) Content-Type: text/html; charset="US-ASCII" Date: Thu, 6 Feb 2003 09:01:31 -0800 To: freebsd-arch@freebsd.org From: GlobeStrat5824@aol.com X-Mailer: Version 5.0 Subject: 2 - 3 hours work = $286 to $1,289 Daily Cash Profit! Organization: Message-Id: <20030206165824.ADD1843F3F@mx1.FreeBSD.org> 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 25 calls per day to customers EXPECTING your call generates
 

25 calls per day to customers EXPECTING your call generates

$2-7K in hefty commissions per week, on-going.

Have a genuine interest in working from home? Telecommute, working from a virtual office set up in your home, in any city of the U.S. No relocation necessary. You never come to an office. This is a flex-time, flex-place opportunity designed to fit around you and your family’s income and time needs.

You can also work your regular job and do this on the "side", as the hours include part time evenings Monday through Thursday, and also varied daytime & evening hours every other weekend.

Commission Range is  $1,000  -  $9,600

Our product is ‘one of a kind’, and extremely unique. It’s very in demand, and high ticket. What’s more, it can be presented to the prospect in a very simple and uncomplicated way.

Cold calling/phone sales experience is highly preferred.

You must be a disciplined self starter - able to work consistently without needing any motivation from others to get the job done. Do not apply if you are not.

You must be comfortable working non-stop, a minimum of 2 to 3 hours per evening on the phone. Do not apply if you are not.

This is an exceptional opportunity for a few special, top performing; ‘crème de le crème’ persons who love to talk to people and who possess higher than average closing ability. Professional experience in recruiting, insurance, debt collection, or financial products is highly desirable.

Requirements:

    • A resident of the continental United States.
    • Extremely ambitious and driven to achieve high levels of commission.
    • Reliable, outgoing, caring, confident, competitive, & assertive.
    • Comfortable doing high volume out-bound calling.  
    • A self starter with strong autonomy and high initiative; able to work independently and consistently without direct supervision.
    • Able to devote a minimum of 14 hours per week; these hours will vary but include evening hours, and also every other weekend to include various daytime and evening hours.
    • Able to follow scripts, training mandates, directions & etc. to the letter.
    • A strong professional, yet personable phone presence.
    • Superb communication & listening skills.
    • Exceptional time management, organizational, and follow up disciplines.
    • A quiet place in which to work, with minimum disruptions.
    • Your own PC with Microsoft Word, and contact management software.
    • Unlimited internet and e-mail capabilities.
    • An active Long Distance Carrier.
    • A dedicated phone line strictly for business purposes.
    • Able to speak and write clear fluent English.

Our representatives work from their homes as independent contractors and enjoy the independence, convenience and challenge it entails. Top closers earn well over $200,000 per year.

By accommodating the flexibility and family/lifestyle needs of our team members, we’ve found that we can attract the ‘very best’ of the very best. We’re only interested in the highest quality, most mature and stable individuals possible.

Our state of the art technology and communications infrastructure ensures that you are properly supported, and that the virtual working environment is seamless in every way possible.

If this sounds like the perfect opportunity for you, follow the following instructions. Again, if you are not qualified, or you do not meet each and every requirement, please do not apply!  NO exceptions.  Thank you.

Do NOT hit reply to this email, it will not reach us.  Send a separate email to AdminSupport@globestrategic73462.com  **Important- type the word ‘Interested’ in the subject line of your email, (with many email services, you will see the word already typed in the subject line for you). Without the word in the subject line, we will not be reached. **Note-any emails with anything else will not reach us.       **To unsubscribe to this list and/or our partner database lists, please use the convenient removal link provided near the bottom of this email.**

Please save all of your questions for after you have received the information we will be sending to you.

We will respond via email within 24 hours with complete details.

  




You're receiving this email because you agreed to receive offers via email from one of our marketing partners. If you believe you have received this email in error or would like to not receive these special offers, please **DO NOT** reply to this email address, or to any other email address contained herein, (such requests won't reach us, and cannot be processed). Please use the link below and allow up to 72 hours for your request to be processed. You may receive additional e-mail during that time. Thank you for your patience. To be removed simply click here.

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 6 11:38:17 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C19A137B405 for ; Thu, 6 Feb 2003 11:38:15 -0800 (PST) Received: from web41205.mail.yahoo.com (web41205.mail.yahoo.com [66.218.93.38]) by mx1.FreeBSD.org (Postfix) with SMTP id 4EA5B43FA3 for ; Thu, 6 Feb 2003 11:38:15 -0800 (PST) (envelope-from gathorpe79@yahoo.com) Message-ID: <20030206193815.71344.qmail@web41205.mail.yahoo.com> Received: from [149.99.118.238] by web41205.mail.yahoo.com via HTTP; Thu, 06 Feb 2003 14:38:15 EST Date: Thu, 6 Feb 2003 14:38:15 -0500 (EST) From: Gary Thorpe Subject: Re: New kernel allocation API To: Jeff Roberson , Julian Elischer Cc: Peter Wemm , Dag-Erling Smorgrav , arch@FreeBSD.ORG In-Reply-To: <20030206040110.V79483-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 --- Jeff Roberson wrote: > On Wed, 5 Feb 2003, Julian Elischer wrote: > > > > > I know several consumers where the size is not known or would be > > expensive to calculate on free. > > > > I bet there are 10x as many that do: > > foo = malloc(sizeof(*foo)); > > Which could just as easily do: > > free(foo, sizeof(*foo)); > > Optimize for the common case. It will make the allocator MUCH > faster. > > Cheers, > Jeff > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message How will it make it faster? By jumping to the group of memory slabs that would match that size? Its too bad it cannot directly find the slab by using the pointer value....how does free() search for the allocated block? Also, with more arguments, the programmer can make more mistakes. What happens if the wrong size is passed to free? It should still work, but it will be slower right? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Feb 6 21:18: 7 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8BF337B401 for ; Thu, 6 Feb 2003 21:17:59 -0800 (PST) Received: from protov.plain.co.nz (protov.plain.co.nz [202.36.174.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id D088043F93 for ; Thu, 6 Feb 2003 21:17:48 -0800 (PST) (envelope-from zombie@i4free.co.nz) Received: from i4free.co.nz (ppp65143.cyberxpress.co.nz [202.49.65.143]) by protov.plain.co.nz (Postfix) with ESMTP id CA63E3C27F for ; Fri, 7 Feb 2003 18:17:24 +1300 (NZDT) Message-ID: <3E434150.4070601@i4free.co.nz> Date: Fri, 07 Feb 2003 18:17:04 +1300 From: Andrew Turner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Subject: Kernel Dependency finding tool Content-Type: multipart/mixed; boundary="------------010606050505090804060806" 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 This is a multi-part message in MIME format. --------------010606050505090804060806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello, I've beed working on the attached tool to find options/drivers that depend on other options/drivers. It currently removes one option at a time from LINT and tryes to build the kernel sending the output to logs. I have only tested this script on my one FreeBSD box and would like some comments and suggestions to improve the script. Andrew Turner --------------010606050505090804060806 Content-Type: text/plain; name="build_deps.sh" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="build_deps.sh" #!/bin/sh # used to find the way home WD=`pwd`/work if [ ! -d ${WD} ] then mkdir -p ${WD} fi # I_ are the initial settings I_BASE="" I_SRCDIR="/usr/src" I_SYSDIR="/sys" I_ARCH=`uname -m` I_LOGDIR=/var/log/bdeps BASE="" SRCDIR="" SUSDIR="" ARCH="" CONFDIR="" SRCBASE="" LOGDIR="" BUILDSTART=1 BUILDEND=0 LINES="" usage () { NAME=`basename $0` echo "Usage:" echo "${NAME} [OPTIONS]" echo echo "where [OPTIONS] are one or more of:" echo echo "--prefix=" echo " Appends src-prefix to start of src-dir" echo "--srcdir=" echo " The main source directory DEFAULT: ${I_SRCDIR}" echo "--arch=" echo " Cross build for arch (untested) DEFAULT: ${I_ARCH}" echo "--logdir=" echo " Log to log-dir DEFAULT: ${I_LOGDIR}" echo "--start=" echo " Start building on config start-cfg" echo " Intended to be used in a cluster" echo "--end=" echo " End building on config end-cfg" echo "--only-build=" echo " Only build config numbered build-cfg" echo "--clean" echo " Clean the temp files and exit" echo "--clean-logs" echo " Clean the logs and exit" } check_opts () { while test "X$1" != "X" do optarg=`expr "X$1" : 'X[^=]*=\(.*\)'` case "$1" in --prefix=*) echo "Using $optarg as src base" BASE=$optarg shift ;; --arch=*) echo "Building for $optarg" ARCH=$optarg shift ;; --srcdir=*) echo "Using $optarg as Source dir" SRCDIR=$optarg shift ;; --logdir=*) echo "Logging to $optarg" LOGDIR=$optarg shift ;; --start=*) echo "Starting the build with config $optarg" BUILDSTART=$optarg shift ;; --end=*) echo "Ending the build with config $optarg" BUILDEND=$optarg shift ;; --only-build=*) echo "Only building config $optarg" BUILDSTART=$optarg BUILDEND=$optarg shift ;; --clean) CLEAN=1 shift ;; --clean-logs) CLEANLOG=1 shift ;; *) usage exit ;; esac done # set the final values to the Initial if are unset if test "X$BASE" = "X" then BASE=${I_BASE} fi if test "X$ARCH" = "X" then ARCH=${I_ARCH} fi if test "X$SRCDIR" = "X" then SRCDIR=${I_SRCDIR} fi if test "X${SYSDIR}" = "X" then SYSDIR=${I_SYSDIR} fi if test "X${LOGDIR}" = "X" then LOGDIR=${I_LOGDIR} fi CONFDIR=${BASEDIR}${SRCDIR}${SYSDIR}/${ARCH}/conf SRCBASE=${BASEDIR}${SRCDIR} EXIT=0 if test "X${CLEAN}" != "X" then do_clean # Clean the Workdir # rm -fr ${WD} # rm -f ${CONFDIR}/CONFIG.* EXIT=1 fi if test "X${CLEANLOG}" != "X" then rm ${LOGDIR}/* EXIT=1 fi if [ ${EXIT} -ne 0 ] then exit 1 fi } # Clean the workdir and config files do_clean () { rm -fr ${WD} rm -f ${CONFDIR}/CONFIG.* } # Remove all temp files on kill on_trap () { do_clean exit 1 } # Load exit traps on HUP, INT, QUIT and TERM load_traps () { trap on_trap 1 2 3 15 } # Build the LINT config make_lint () { echo "Building the LINT config from NOTES" cd ${CONFDIR} make LINT > /dev/null cd ${WD} } # Copy the LINT config file copy_lint () { echo "Copying LINT file" cp ${CONFDIR}/LINT ${WD} } # Splitd lint into 2 files: # 1) the parts that are needed in all config files # 2) the parts that are changed in each config file split_lint () { echo "Splitting LINT file" # rm -f ${WD}/LINT.all ALL_OPTS="ident machine profile cpu maxusers makeoptions" SOME_OPTS="device options" rm -f ${WD}/LINT.* for opt in $ALL_OPTS do awk "{ if ( \$1 == \"$opt\" ) { print \$0 } }" < LINT >> LINT.all done for opt in $SOME_OPTS do awk "{ if ( \$1 == \"$opt\" ) { print \$0 } }" < LINT >> LINT.some done } # Create the n config files build_configs () { if [ -d ${WD}/configure ] then rm -f ${WD}/configure/CONFIG.* else mkdir ${WD}/configure fi LINES=`cat LINT.some | wc -l | xargs echo` echo "Creating ${LINES} config files" n=0 while [ $n -lt $LINES ] do n=`expr $n + 1` cp ${WD}/LINT.all ${WD}/configure/CONFIG.$n awk "BEGIN { LINE=0 } { LINE++ ; if ( LINE != $n ) { print \$0 } }" < LINT.some >> configure/CONFIG.$n done } copy_configs () { echo "Copying config files to build" cp ${WD}/configure/CONFIG.* ${CONFDIR} } build_kernels () { echo "Building ${LINES} configs" n=`expr $BUILDSTART - 1` if [ $BUILDEND -eq 0 ] then BUILDEND=$LINES elif [ $BUILDEND -gt $LINES ] then BUILDEND=$LINES fi cd ${SRCBASE} while [ $n -lt $BUILDEND ] do n=`expr $n + 1` echo "Building config $n starts at `date`" date > ${LOGDIR}/buildkernel.$n make buildkernel KERNCONF=CONFIG.$n >> ${LOGDIR}/buildkernel.$n 2>&1 if [ $? -ne 0 ] then #touch ${LOGDIR}/fail.$n head -n $n ${WD}/LINT.some | tail -n 1 > ${LOGDIR}/fail.$n else head -n $n ${WD}/LINT.some | tail -n 1 > ${LOGDIR}/pass.$n fi date >> ${LOGDIR}/buildkernel.$n done cd ${WD} } load_traps check_opts $* make_lint copy_lint split_lint build_configs copy_configs build_kernels --------------010606050505090804060806-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 3:28:41 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C12D137B401 for ; Fri, 7 Feb 2003 03:28:40 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A519243F85 for ; Fri, 7 Feb 2003 03:28:36 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 86205536E; Fri, 7 Feb 2003 12:28:33 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Gary Thorpe Cc: Jeff Roberson , Julian Elischer , Peter Wemm , arch@FreeBSD.ORG Subject: Re: New kernel allocation API From: Dag-Erling Smorgrav Date: Fri, 07 Feb 2003 12:28:33 +0100 In-Reply-To: <20030206193815.71344.qmail@web41205.mail.yahoo.com> (Gary Thorpe's message of "Thu, 6 Feb 2003 14:38:15 -0500 (EST)") Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) References: <20030206193815.71344.qmail@web41205.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Gary Thorpe writes: > Also, with more arguments, the programmer can make more mistakes. What > happens if the wrong size is passed to free? It should still work, but > it will be slower right? Ideally, it will cause a panic when compiled with INVARIANTS. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 15:16: 7 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5895837B401 for ; Fri, 7 Feb 2003 15:16:06 -0800 (PST) Received: from citymail.com.tw (148.1.30.61.isp.tfn.net.tw [61.30.1.148]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E58843F75 for ; Fri, 7 Feb 2003 15:15:54 -0800 (PST) (envelope-from chin1122@citymail.com.tw) From: jerry@FreeBSD.ORG Subject: ¦¬¤J¼W¥[ªº¤èªk Reply-To: ch1n1122@citymail.com.tw Date: 08 Feb 2003 07:36:04 +0800 Organization: Foobar Inc. X-Mailer: Gammadyne Mailer x-delete-me: 1 (this tells Gammadyne's server to delete the message) MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit Message-Id: <20030207231554.5E58843F75@mx1.FreeBSD.org> To: undisclosed-recipients: ; 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 ¦L¶r¾÷

·s¦~§ª«°e±z¤@¥x¦L¶r¾÷ ...

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 18: 9:53 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A71C737B401 for ; Fri, 7 Feb 2003 18:09:51 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C981443F85 for ; Fri, 7 Feb 2003 18:09:50 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h1829Xx63174; Fri, 7 Feb 2003 21:09:33 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 7 Feb 2003 21:09:33 -0500 (EST) From: Jeff Roberson To: Gary Thorpe Cc: Julian Elischer , Peter Wemm , Dag-Erling Smorgrav , Subject: Re: New kernel allocation API In-Reply-To: <20030206193815.71344.qmail@web41205.mail.yahoo.com> Message-ID: <20030207205529.K72073-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 6 Feb 2003, Gary Thorpe wrote: > How will it make it faster? By jumping to the group of memory slabs > that would match that size? Yes. Right now in malloc you have to look up the zone based on the address. I have a hack that lets us do this in constant time. It basically goes like this: 1) Resolve the kernel virtual address into the physical page by using pmap_kextract. This is _expensive_. 2) Follow the page's object pointer which is overloaded to mean slab. 3) Follow the slab's back pointer to it's zone. 4) Free the item to the zone passing in the slab pointer as an optimization. This could go something like this: 1) Lookup the zone in a small table based on the size passed to free. 2) Free the item to that zone 3) Lookup the slab address based on the address of the object or the zone's hash table. The reason that you cant do this now is because you don't know if the item's slab structure is allocated along with the item. So you cant just use address mask tricks to lookup the slab. This is done to support large objects. > Its too bad it cannot directly find the > slab by using the pointer value....how does free() search for the > allocated block? The old code used a large fixed size array that represented all of kmem_map. This no longer works because the allocator can return pages that are outside of kmem map. It does this on alpha, ia64, and sparc64 to use direct mapped regions of address space for kernel memory. > Also, with more arguments, the programmer can make more mistakes. What > happens if the wrong size is passed to free? It should still work, but > it will be slower right? I agree. You'd panic because the item would not be found in that zone. I think we should ignore this until someone is prepared to really address all the issues surrounding this api. I don't see any sense in defining two new entry points when they give no distinct capabilities. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 18:10:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD13A37B401 for ; Fri, 7 Feb 2003 18:10:49 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C27E743FA3 for ; Fri, 7 Feb 2003 18:10:48 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h182ARZ63567; Fri, 7 Feb 2003 21:10:28 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 7 Feb 2003 21:10:27 -0500 (EST) From: Jeff Roberson To: Vallo Kallaste Cc: Marijn Meijles , Subject: Re: New scheduler problem In-Reply-To: <20030206094040.GA2000@kevad.internal> Message-ID: <20030207211000.P72073-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Thu, 6 Feb 2003, Vallo Kallaste wrote: > On Wed, Feb 05, 2003 at 09:12:36PM +0100, Marijn Meijles > wrote: > > > I just tried the new scheduler (yesterdays cvsup), but it gives horrible > > interactve performance in some situations. Especially with mixed interactive > > and non-interactive applications like mozilla. This is perfectly > > Running two seti@home processes (2 CPU's) at nice 19 kills > interactive peformance entirely. Worse than 300baud modem on the > console, mouse will not work at all. SCHED_4BSD is fine. > -- I botched it last weekend. I will fix it this weekend. I'll let you know when it's ready to go again. I appreciate the exposure. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 18:27:25 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8152F37B401 for ; Fri, 7 Feb 2003 18:27:24 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FD2D43FDF for ; Fri, 7 Feb 2003 18:27:23 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id F0B59AE22C; Fri, 7 Feb 2003 18:27:22 -0800 (PST) Date: Fri, 7 Feb 2003 18:27:22 -0800 From: Alfred Perlstein To: Jeff Roberson Cc: Gary Thorpe , Julian Elischer , Peter Wemm , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030208022722.GB88781@elvis.mu.org> References: <20030206193815.71344.qmail@web41205.mail.yahoo.com> <20030207205529.K72073-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030207205529.K72073-100000@mail.chesapeake.net> User-Agent: Mutt/1.4i 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 * Jeff Roberson [030207 18:10] wrote: > On Thu, 6 Feb 2003, Gary Thorpe wrote: > > > How will it make it faster? By jumping to the group of memory slabs > > that would match that size? > > Yes. Right now in malloc you have to look up the zone based on the > address. I have a hack that lets us do this in constant time. It > basically goes like this: *snip* It seems that you've missed reading the original allocator or something, there's a cheap way to do this that doesn't require too much overhead. Since you know the max size of the malloc arena you simply allocated "size of malloc arena" / granulatity to realize "number of pointers". You then allocate "number of pointers". Now as you allocate portions of the malloc arena for slabs you point the pointers corresponding to the granule at the slab. Now you can take any pointer and figure out which granule it is associated with in O(1) time. Yes there is a space tradeoff, but it avoids this pmap_kextract nonsense and multiple pointer dereferences. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 19:17:34 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E5C937B401 for ; Fri, 7 Feb 2003 19:17:33 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D444543F85 for ; Fri, 7 Feb 2003 19:17:32 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h183HNL94536; Fri, 7 Feb 2003 22:17:23 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 7 Feb 2003 22:17:23 -0500 (EST) From: Jeff Roberson To: Alfred Perlstein Cc: Gary Thorpe , Julian Elischer , Peter Wemm , Dag-Erling Smorgrav , Subject: Re: New kernel allocation API In-Reply-To: <20030208022722.GB88781@elvis.mu.org> Message-ID: <20030207221623.V72073-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Fri, 7 Feb 2003, Alfred Perlstein wrote: > *snip* > > It seems that you've missed reading the original allocator or something, > there's a cheap way to do this that doesn't require too much overhead. It seems that you've missed reading my email. "The old code used a large fixed size array that represented all of kmem_map. This no longer works because the allocator can return pages that are outside of kmem map. It does this on alpha, ia64, and sparc64 to use direct mapped regions of address space for kernel memory." > Yes there is a space tradeoff, but it avoids this pmap_kextract > nonsense and multiple pointer dereferences. It's not so much nonsense as it is a solution. Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 20:17: 6 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F29C37B401 for ; Fri, 7 Feb 2003 20:17:05 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5E4843F3F for ; Fri, 7 Feb 2003 20:17:04 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 7DCB5AE22C; Fri, 7 Feb 2003 20:16:59 -0800 (PST) Date: Fri, 7 Feb 2003 20:16:59 -0800 From: Alfred Perlstein To: Jeff Roberson Cc: arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030208041659.GC88781@elvis.mu.org> References: <20030208022722.GB88781@elvis.mu.org> <20030207221623.V72073-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030207221623.V72073-100000@mail.chesapeake.net> User-Agent: Mutt/1.4i 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 * Jeff Roberson [030207 19:17] wrote: > > > On Fri, 7 Feb 2003, Alfred Perlstein wrote: > > > *snip* > > > > It seems that you've missed reading the original allocator or something, > > there's a cheap way to do this that doesn't require too much overhead. > > It seems that you've missed reading my email. > > "The old code used a large fixed size array that represented all of > kmem_map. This no longer works because the allocator can return pages > that are outside of kmem map. It does this on alpha, ia64, and sparc64 to > use direct mapped regions of address space for kernel memory." > > > Yes there is a space tradeoff, but it avoids this pmap_kextract > > nonsense and multiple pointer dereferences. > > It's not so much nonsense as it is a solution. Doh, I guess I should be paying more attention, sorry for that. What advantage do you get from using direct mapped pages? Why not alias/map them into kmem map? I know you'd pay a penalty for the vm overhead, but you'd gain back the fixed array trick. I'm probably missing something? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 20:20:26 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB5DE37B401 for ; Fri, 7 Feb 2003 20:20:24 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84D7143F85 for ; Fri, 7 Feb 2003 20:20:24 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 4DF71AE28A; Fri, 7 Feb 2003 20:20:24 -0800 (PST) Date: Fri, 7 Feb 2003 20:20:24 -0800 From: Alfred Perlstein To: Jeff Roberson Cc: Gary Thorpe , Julian Elischer , Peter Wemm , Dag-Erling Smorgrav , arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030208042024.GD88781@elvis.mu.org> References: <20030208022722.GB88781@elvis.mu.org> <20030207221623.V72073-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030207221623.V72073-100000@mail.chesapeake.net> User-Agent: Mutt/1.4i 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 * Jeff Roberson [030207 19:17] wrote: > On Fri, 7 Feb 2003, Alfred Perlstein wrote: > > > *snip* > > > > It seems that you've missed reading the original allocator or something, > > there's a cheap way to do this that doesn't require too much overhead. > > It seems that you've missed reading my email. > > "The old code used a large fixed size array that represented all of > kmem_map. This no longer works because the allocator can return pages > that are outside of kmem map. It does this on alpha, ia64, and sparc64 to > use direct mapped regions of address space for kernel memory." Another point, even if it doesn't make sense to do the kmem_map thing anymore, it might make sense to use a hash function based on the real virtual address and chain the structures off of that. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 20:38:55 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D416937B401 for ; Fri, 7 Feb 2003 20:38:53 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07E1443F75 for ; Fri, 7 Feb 2003 20:38:53 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.6/8.12.6) with ESMTP id h184enNk033107; Fri, 7 Feb 2003 23:40:49 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.6/8.12.6/Submit) id h184enOI033106; Fri, 7 Feb 2003 23:40:49 -0500 (EST) Date: Fri, 7 Feb 2003 23:40:49 -0500 From: Jake Burkholder To: Alfred Perlstein Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030207234049.A32864@locore.ca> References: <20030208022722.GB88781@elvis.mu.org> <20030207221623.V72073-100000@mail.chesapeake.net> <20030208041659.GC88781@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030208041659.GC88781@elvis.mu.org>; from bright@mu.org on Fri, Feb 07, 2003 at 08:16:59PM -0800 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 Apparently, On Fri, Feb 07, 2003 at 08:16:59PM -0800, Alfred Perlstein said words to the effect of; > * Jeff Roberson [030207 19:17] wrote: > > > > > > On Fri, 7 Feb 2003, Alfred Perlstein wrote: > > > > > *snip* > > > > > > It seems that you've missed reading the original allocator or something, > > > there's a cheap way to do this that doesn't require too much overhead. > > > > It seems that you've missed reading my email. > > > > "The old code used a large fixed size array that represented all of > > kmem_map. This no longer works because the allocator can return pages > > that are outside of kmem map. It does this on alpha, ia64, and sparc64 to > > use direct mapped regions of address space for kernel memory." > > > > > Yes there is a space tradeoff, but it avoids this pmap_kextract > > > nonsense and multiple pointer dereferences. > > > > It's not so much nonsense as it is a solution. > > Doh, I guess I should be paying more attention, sorry for that. > > What advantage do you get from using direct mapped pages? Why not > alias/map them into kmem map? I know you'd pay a penalty for the > vm overhead, but you'd gain back the fixed array trick. I'm probably > missing something? It lets you use the largest page size supported by the tlb (256 megs for ia64 (!)), and it doesn't take a tlb shootdown to add or remove a mapping because they never change. Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Feb 7 20:51:50 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 542C137B401 for ; Fri, 7 Feb 2003 20:51:49 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02E8E43FB1 for ; Fri, 7 Feb 2003 20:51:49 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 61B9FAE25C; Fri, 7 Feb 2003 20:51:45 -0800 (PST) Date: Fri, 7 Feb 2003 20:51:45 -0800 From: Alfred Perlstein To: Jake Burkholder Cc: Jeff Roberson , arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030208045145.GE88781@elvis.mu.org> References: <20030208022722.GB88781@elvis.mu.org> <20030207221623.V72073-100000@mail.chesapeake.net> <20030208041659.GC88781@elvis.mu.org> <20030207234049.A32864@locore.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030207234049.A32864@locore.ca> User-Agent: Mutt/1.4i 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 * Jake Burkholder [030207 20:38] wrote: > Apparently, On Fri, Feb 07, 2003 at 08:16:59PM -0800, > Alfred Perlstein said words to the effect of; > > > Doh, I guess I should be paying more attention, sorry for that. > > > > What advantage do you get from using direct mapped pages? Why not > > alias/map them into kmem map? I know you'd pay a penalty for the > > vm overhead, but you'd gain back the fixed array trick. I'm probably > > missing something? > > It lets you use the largest page size supported by the tlb (256 megs for > ia64 (!)), and it doesn't take a tlb shootdown to add or remove a mapping > because they never change. That makes sense, at first the idea of requiring free to take a size really seemed to suck, but it would be optional right? Other sections can still use jeff's lookup method when free is not passed a size right? This is somewhat premature as we should probably just convert over most of the fixed sized structures to use zones/slabs, but offering the "optimized" free sounds nice. If you guys have the time, go for it. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 8 0:23: 8 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEFD837B401 for ; Sat, 8 Feb 2003 00:22:55 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4569643F85 for ; Sat, 8 Feb 2003 00:22:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h188MkSJ005279; Sat, 8 Feb 2003 00:22:47 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h188Mi15005276; Sat, 8 Feb 2003 00:22:44 -0800 (PST) Date: Sat, 8 Feb 2003 00:22:44 -0800 (PST) From: Matthew Dillon Message-Id: <200302080822.h188Mi15005276@apollo.backplane.com> To: Jeff Roberson Cc: Gary Thorpe , Julian Elischer , Peter Wemm , Dag-Erling Smorgrav , Subject: Re: New kernel allocation API References: <20030207205529.K72073-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 : :On Thu, 6 Feb 2003, Gary Thorpe wrote: : :> How will it make it faster? By jumping to the group of memory slabs :> that would match that size? : :Yes. Right now in malloc you have to look up the zone based on the :address. I have a hack that lets us do this in constant time. It :basically goes like this: If you take a look at /usr/src/lib/libstand/zalloc* you will see that the allocation interface I wrote for libstand needs the size passed to it in the freeing code. For example. I've done it this way in virtually every allocator I've ever written, because it gives any allocator API *huge* flexibility, and I expect probably 99% of our kernel would trivially be able to pass the size to the freeing code. However, it is not precisely necessary from the point of view of a slab allocator. If the slab allocator allocates large, aligned meta-blocks, then calculating the base of the slab is utterly trivial, e.g. it is just (ptr & (128 * 1024 - 1)), and the slab header can contain the granularity for the slab. I've included slab code I've been working on. The code is for another project, but, Jeff, you are welcome to snarf any bits that fit in with your allocator. This code is somewhat tested but not life-tested. The code provides instant allocation and instant deallocation, O(1) time with *extreme* performance and good cache and TLB characteristics. It just so happens I have it conditionalized for standalone testing, just compile with -DSTANDALONE -DWITH_LIBC. The only thing I haven't done yet is try to optimize detection of individual free pages (at least when the allocation size does not result in an allocation overlapping a page), but I have most of the infrastructure in place (which is also what gets me the good TLB hit characteristics) that would be required to do that. -Matt /* * LIBDUX/SLABALLOC.C - DUX memory management * * This module implements a slab allocator. It uses sys_valloc(), * sys_valloc_aligned(), and sys_vfree() to manage the underlying * memory. * * A slab allocator reserves a ZONE for each chunk size, then lays the * chunks out in an array in the zone. Allocation and deallocation is * near instantanious and fragmentation is minimized. The downside is * in VM usesage (~80 zones x 128K = 10MB) and a moderate, but * reasonable amount of memory overhead in high volumes. In low volumes * memory overhead might be an issue, so a general purpose allocator * might use something more compact like the LVZ or HVZ allocator for * the first 128K (which can mix several chunk sizes in the same page), * and then revert to this slab allocator for the remainder. * * Alloc Size Chunking Number of zones * 0-127 8 16 * 128-255 16 8 * 256-511 32 8 * 512-1023 64 8 * 1024-2047 128 8 * 2048-4095 256 8 * 4096-8191 512 8 * 8192-16383 1024 8 * 16384-32767 2048 8 * (if PAGE_SIZE is 4K the maximum zone allocation is 16383) */ #if defined(WITH_LIBC) #include #include #include #include #include #include #include #include #define arysize(ary) (sizeof(ary)/sizeof((ary)[0])) #if defined(STANDALONE) #define kassert(cond) if (!(cond)) _kassert(__FILE__, __LINE__, #cond) #ifndef DIAGNOSTIC #define DIAGNOSTIC #endif #endif #else #include "defs.h" Export void slab_setup(void); Export void *slab_alloc(uintptr_t bytes); Export void slab_free(void *ptr, uintptr_t bytes); #endif #define MIN_CHUNK_SIZE 8 #define MIN_CHUNK_MASK (MIN_CHUNK_SIZE - 1) #define ZONE_SIZE (128 * 1024) #define ZONE_ALLOC_LIMIT 32768 #define ZONE_MAGIC 0x736c6162 #define ZONE_RELS_THRESH 2 #define IN_SAME_PAGE_MASK (~(intptr_t)PAGE_MASK | MIN_CHUNK_MASK) #if ZONE_ALLOC_LIMIT == 16384 #define NZONES 72 #elif ZONE_ALLOC_LIMIT == 32768 #define NZONES 80 #else #error "I couldn't figure out NZONES" #endif typedef struct Chunk { struct Chunk *c_Next; } Chunk; typedef struct Zone { struct Zone *z_Next; /* ZoneAry[] link if z_NFree non-zero */ int z_Magic; int z_NFree; /* total free chunks / ualloc space in zone */ int z_NMax; /* maximum free chunks */ int z_UAlloc; /* allocation offset into uninitialized space */ int z_ChunkSize; /* chunk size for validation */ int z_FirstFreePg; /* chunk list on a page-by-page basis */ int z_ZoneIndex; Chunk *z_PageAry[ZONE_SIZE / PAGE_SIZE]; } Zone; static Zone *ZoneAry[NZONES]; /* linked list of zones NFree > 0 */ static Zone *FreeZones; /* whole zones that have become free */ static int NFreeZones; #if defined(WITH_LIBC) static void *sys_valloc(uintptr_t bytes); static void *sys_valloc_aligned(uintptr_t bytes); static void sys_vfree(void *ptr, uintptr_t bytes); #if defined(STANDALONE) static void _kassert(const char *file, int line, const char *cond); static void kpanic(const char *ctl, ...); #endif #endif void slab_setup(void) { } static __inline int zoneindex(uintptr_t *bytes) { unsigned int n = (unsigned int)*bytes; /* unsigned for shift opt */ if (n < 128) { *bytes = n = (n + 7) & ~7; return(n / 8); } if (n < 256) { *bytes = n = (n + 15) & ~15; return(n / 16 + 8); } if (n < 8192) { if (n < 512) { *bytes = n = (n + 31) & ~31; return(n / 32 + 16); } if (n < 1024) { *bytes = n = (n + 63) & ~63; return(n / 64 + 24); } if (n < 2048) { *bytes = n = (n + 127) & ~127; return(n / 128 + 32); } if (n < 4096) { *bytes = n = (n + 255) & ~255; return(n / 256 + 40); } *bytes = n = (n + 511) & ~511; return(n / 512 + 48); } #if ZONE_ALLOC_LIMIT > 8192 if (n < 16384) { *bytes = n = (n + 1023) & ~1023; return(n / 1024 + 56); } #endif #if ZONE_ALLOC_LIMIT > 16384 if (n < 32768) { *bytes = n = (n + 2047) & ~2047; return(n / 2048 + 64); } #endif kassert(0); /* unexpected byte count */ return(0); } void * slab_alloc(uintptr_t bytes) { Zone *z; Chunk *chunk; int zi; /* * Degenerate cases */ kassert(bytes > 0); if ((bytes & PAGE_MASK) == 0 || bytes > ZONE_ALLOC_LIMIT) { chunk = sys_valloc((bytes + PAGE_MASK) & ~PAGE_MASK); return(chunk); } /* * Zone case. Attempt to allocate out of an existing zone. First * try the free list, then allocate out of unallocated space. If we * find a good zone move it to the head of the list (we might have * thousands of zones in the list). */ zi = zoneindex(&bytes); if ((z = ZoneAry[zi]) != NULL) { kassert(z->z_NFree > 0); /* * Remove us from the ZoneAry[] when we become empty */ if (--z->z_NFree == 0) { ZoneAry[zi] = z->z_Next; z->z_Next = NULL; #if defined(STANDALONE) printf("Zone %p fully allocated\n", z); #endif } /* * Locate a chunk in a free page. This attempts to localize * reallocations into earlier pages without us having to sort * the chunk list. A chunk may still overlap a page boundary. */ while (z->z_FirstFreePg < arysize(z->z_PageAry)) { if ((chunk = z->z_PageAry[z->z_FirstFreePg]) != NULL) { #ifdef DIAGNOSTIC /* * Diagnostic: c_Next is not total garbage. */ kassert(chunk->c_Next == NULL || ((intptr_t)chunk->c_Next & IN_SAME_PAGE_MASK) == ((intptr_t)chunk & IN_SAME_PAGE_MASK)); #endif z->z_PageAry[z->z_FirstFreePg] = chunk->c_Next; return(chunk); } ++z->z_FirstFreePg; } chunk = (Chunk *)((char *)z + z->z_UAlloc); z->z_UAlloc += bytes; kassert(z->z_UAlloc < ZONE_SIZE); return(chunk); } /* * If all zones are exhausted we need to allocate a new zone for this * size. */ { int off; if ((z = FreeZones) != NULL) { FreeZones = z->z_Next; } else { z = sys_valloc_aligned(ZONE_SIZE); } bzero(z, sizeof(Zone)); off = (sizeof(Zone) + MIN_CHUNK_MASK) & ~MIN_CHUNK_MASK; z->z_Magic = ZONE_MAGIC; z->z_ZoneIndex = zi; z->z_NMax = (ZONE_SIZE - off) / bytes; z->z_NFree = z->z_NMax - 1; z->z_UAlloc = off + bytes; z->z_ChunkSize = bytes; z->z_FirstFreePg = arysize(z->z_PageAry); chunk = (Chunk *)((char *)z + off); z->z_Next = ZoneAry[zi]; #if defined(STANDALONE) printf("Allocating new zone %p chunk %d %d/%d\n", z, z->z_ChunkSize, z->z_NFree, z->z_NMax); #endif ZoneAry[zi] = z; } return(chunk); } void slab_free(void *ptr, uintptr_t bytes) { Zone *z; Chunk *chunk; int pgno; /* * Degenerate cases */ kassert(bytes > 0); if ((bytes & PAGE_MASK) == 0 || bytes > ZONE_ALLOC_LIMIT) { sys_vfree(ptr, (bytes + PAGE_MASK) & ~PAGE_MASK); return; } /* * Zone case. Figure out the zone based on the fact that it is * ZONE_SIZE aligned. */ z = (Zone *)((intptr_t)ptr & ~(ZONE_SIZE - 1)); kassert(z->z_Magic == ZONE_MAGIC); #ifdef DIAGNOSTIC /* * Diagnostic: chunk size must match */ (void)zoneindex(&bytes); kassert(z->z_ChunkSize == bytes); #endif pgno = ((char *)ptr - (char *)z) >> PAGE_SHIFT; if (z->z_FirstFreePg > pgno) z->z_FirstFreePg = pgno; chunk = ptr; #ifdef DIAGNOSTIC /* * Diagnostic: attempt to detect a double-free (not perfect). */ if (((intptr_t)chunk->c_Next - (intptr_t)z) >> PAGE_SHIFT == pgno) { Chunk *scan; for (scan = z->z_PageAry[pgno]; scan; scan = scan->c_Next) { if (scan == chunk) kpanic("Double free at %p", chunk); } } #endif chunk->c_Next = z->z_PageAry[pgno]; z->z_PageAry[pgno] = chunk; /* * Bump the number of free chunks. If it becomes non-zero the zone * must be added back onto the appropriate list. */ if (z->z_NFree++ == 0) { z->z_Next = ZoneAry[z->z_ZoneIndex]; ZoneAry[z->z_ZoneIndex] = z; #if defined(STANDALONE) printf("Zone %p no longer fully allocated (%p)\n", z, z->z_Next); #endif } /* * If the zone becomes totally free, and there are other zones we * can allocate from, remove this one from the list. */ #if defined(STANDALONE) printf("NFree %d/%d\n", z->z_NFree, z->z_NMax); #endif if (z->z_NFree == z->z_NMax && (z->z_Next || ZoneAry[z->z_ZoneIndex] != z) ) { Zone **pz; for (pz = &ZoneAry[z->z_ZoneIndex]; z != *pz; pz = &(*pz)->z_Next) ; *pz = z->z_Next; z->z_Magic = -1; if (NFreeZones == ZONE_RELS_THRESH) { z->z_Next = FreeZones->z_Next; #if defined(STANDALONE) printf("Destroying idle zone %p\n", FreeZones); #endif sys_vfree(FreeZones, ZONE_SIZE); FreeZones = z; } else { z->z_Next = FreeZones; FreeZones = z; ++NFreeZones; } #if defined(STANDALONE) printf("Returning completely free zone %p to freelist\n", z); #endif } } #if defined(WITH_LIBC) static void * sys_valloc(uintptr_t bytes) { char *ptr; ptr = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); if (ptr == MAP_FAILED) ptr = NULL; return(ptr); } static void * sys_valloc_aligned(uintptr_t bytes) { char *ptr; uintptr_t extra; ptr = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); if (ptr == MAP_FAILED) return(NULL); if ((uintptr_t)ptr & (bytes - 1)) { munmap(ptr, bytes); ptr = mmap(NULL, bytes * 2, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0); if (ptr == MAP_FAILED) return(NULL); if ((extra = (uintptr_t)ptr & (bytes - 1)) == 0) { munmap(ptr + bytes, bytes); } else { extra = bytes - extra; munmap(ptr, extra); ptr += extra; munmap(ptr + bytes, bytes - extra); } } return(ptr); } static void sys_vfree(void *ptr, uintptr_t bytes) { munmap(ptr, bytes); } #if defined(STANDALONE) int main(int ac, char **av) { char buf[256]; Zone *z; slab_setup(); printf("> "); fflush(stdout); while (fgets(buf, sizeof(buf), stdin) != NULL) { intptr_t v1 = 0; intptr_t v2 = 0; char *ptr; if (buf[0]) { ptr = buf + 1; v1 = strtoul(ptr, &ptr, 0); v2 = strtoul(ptr, &ptr, 0); } switch(buf[0]) { case 'a': ptr = slab_alloc(v1); z = (Zone *)((intptr_t)ptr & ~(ZONE_SIZE - 1)); printf("allocate %p %d\tZone %p %d/%d\n", ptr, v1, z, z->z_NFree, z->z_NMax); break; case 'f': slab_free((char *)v1, v2); break; case '?': case 'h': printf("a \tallocate memory\n"); printf("f \tfree memory\n"); printf("?/h\t\thelp\n"); break; default: printf("? bad command\n"); break; } printf("> "); fflush(stdout); } return(0); } static void _kassert(const char *file, int line, const char *cond) { fprintf(stderr, "%s line %d: %s\n", file, line, cond); *(int *)0 = 1; } static void kpanic(const char *ctl, ...) { va_list va; va_start(va, ctl); vfprintf(stderr, ctl, va); va_end(va); fprintf(stderr, "\n"); *(int *)0 = 1; } #endif #endif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 8 0:37:29 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63ABC37B401 for ; Sat, 8 Feb 2003 00:37:28 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1C8643FAF for ; Sat, 8 Feb 2003 00:37:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h188bPSJ005460; Sat, 8 Feb 2003 00:37:25 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h188bOm1005459; Sat, 8 Feb 2003 00:37:24 -0800 (PST) Date: Sat, 8 Feb 2003 00:37:24 -0800 (PST) From: Matthew Dillon Message-Id: <200302080837.h188bOm1005459@apollo.backplane.com> To: Jeff Roberson , Gary Thorpe , Julian Elischer , Peter Wemm , Dag-Erling Smorgrav , Subject: Re: New kernel allocation API References: <20030207205529.K72073-100000@mail.chesapeake.net> <200302080822.h188Mi15005276@apollo.backplane.com> 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 : e.g. it is just (ptr & (128 * 1024 - 1)), and the slab header can : contain the granularity for the slab. Oops. I meant: (ptr & ~(uintptr_t)(128 * 1024 - 1)) -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 8 5:31:45 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0D1437B401 for ; Sat, 8 Feb 2003 05:31:43 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0788643F93 for ; Sat, 8 Feb 2003 05:31:43 -0800 (PST) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h18DVfqV018903 for ; Sat, 8 Feb 2003 14:31:41 +0100 (CET) (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org Subject: Indiscriminately installing all .h files in /usr/include/* From: phk@phk.freebsd.dk In-Reply-To: Your message of "Sat, 08 Feb 2003 05:25:48 PST." <200302081325.h18DPmrB010982@repoman.freebsd.org> Date: Sat, 08 Feb 2003 14:31:41 +0100 Message-ID: <18902.1044711101@critter.freebsd.dk> 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 In message <200302081325.h18DPmrB010982@repoman.freebsd.org>, Poul-Henning Kamp writes: >phk 2003/02/08 05:25:48 PST > > Modified files: > etc/mtree BSD.include.dist > include Makefile > Log: > Install geom include files. Not being the kind of guy who casually walks through /usr/include once in a while, I only now just discovered that "make installincludes" indiscriminately installs all .h files under /usr/include. I understand the desirablity of simple makefile magic for this task, but couldn't we agree on some sort of magic-marker to put in files we want or don't want installed in /usr/include ? Obviously the least intrusive option is to add a "/* NO_USR_INCLUDE */" in the files we don't want exported, but I would really prefer that exportation of a .h file be an explicit action and therefore prefer if the marker actually were "/* USR_INCLUDE */" in the files we want exported. Am I just being oldfashioned here ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 8 23:46:11 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5160C37B401 for ; Sat, 8 Feb 2003 23:46:09 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0468643F85 for ; Sat, 8 Feb 2003 23:46:09 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id EC6962A8B4; Sat, 8 Feb 2003 23:46:04 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Jake Burkholder Cc: Alfred Perlstein , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: New kernel allocation API In-Reply-To: <20030207234049.A32864@locore.ca> Date: Sat, 08 Feb 2003 23:46:04 -0800 From: Peter Wemm Message-Id: <20030209074604.EC6962A8B4@canning.wemm.org> 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 Jake Burkholder wrote: > Apparently, On Fri, Feb 07, 2003 at 08:16:59PM -0800, > Alfred Perlstein said words to the effect of; > > > * Jeff Roberson [030207 19:17] wrote: > > > > > > > > > On Fri, 7 Feb 2003, Alfred Perlstein wrote: > > > > > > > *snip* > > > > > > > > It seems that you've missed reading the original allocator or something , > > > > there's a cheap way to do this that doesn't require too much overhead. > > > > > > It seems that you've missed reading my email. > > > > > > "The old code used a large fixed size array that represented all of > > > kmem_map. This no longer works because the allocator can return pages > > > that are outside of kmem map. It does this on alpha, ia64, and sparc64 t o > > > use direct mapped regions of address space for kernel memory." > > > > > > > Yes there is a space tradeoff, but it avoids this pmap_kextract > > > > nonsense and multiple pointer dereferences. > > > > > > It's not so much nonsense as it is a solution. > > > > Doh, I guess I should be paying more attention, sorry for that. > > > > What advantage do you get from using direct mapped pages? Why not > > alias/map them into kmem map? I know you'd pay a penalty for the > > vm overhead, but you'd gain back the fixed array trick. I'm probably > > missing something? > > It lets you use the largest page size supported by the tlb (256 megs for > ia64 (!)), and it doesn't take a tlb shootdown to add or remove a mapping > because they never change. And there is hardware support for direct mapping on alpha as well, so it completely bypasses the TLB entirely for significant benefits. For x86-64 there'll likely be up to 2^39 of direct mapped space as well, but using 2MB pages (use an entire level 4 directory slot for direct mapping to avoid the APTD evilness). We just dont have the space to do this on plain x86 :-(. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Feb 8 23:57: 7 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A44AD37B401 for ; Sat, 8 Feb 2003 23:57:06 -0800 (PST) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58D3043FA3 for ; Sat, 8 Feb 2003 23:57:06 -0800 (PST) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1F771AE162; Sat, 8 Feb 2003 23:57:06 -0800 (PST) Date: Sat, 8 Feb 2003 23:57:06 -0800 From: Alfred Perlstein To: Peter Wemm Cc: Jake Burkholder , Jeff Roberson , arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030209075706.GO88781@elvis.mu.org> References: <20030207234049.A32864@locore.ca> <20030209074604.EC6962A8B4@canning.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030209074604.EC6962A8B4@canning.wemm.org> User-Agent: Mutt/1.4i 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 * Peter Wemm [030208 23:46] wrote: > > And there is hardware support for direct mapping on alpha as well, so it > completely bypasses the TLB entirely for significant benefits. For x86-64 > there'll likely be up to 2^39 of direct mapped space as well, but using 2MB > pages (use an entire level 4 directory slot for direct mapping to avoid the > APTD evilness). We just dont have the space to do this on plain x86 :-(. It seems to me that someone should run some tests to get numbers to determine if the tlb optimization helps more than the kmem-array optimization. However the problem with that is that much more of the kernel should be converted to use zones/slabs before counting on the data gathered. I'm trusting you guys that avoiding the tlb shootdowns help quite a bit, but then again the cost of each free(9) seems quite high. I may see if I can convert some paths in the kernel to use zones. :) -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message