Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote: Karl Denninger wrote: I've found FreeBSD to outperform NT-anything in any task you throw at the machine from web service to Samba for file and print service for PCs running Windows. Granted. Perhaps we're seeing an artifact of NT's developers focussing on optimizing their system for good benchmark performance rather than good real-world performance. 'twill be interesting to see the offical report to find out where the various strengths and weaknesses really are. - mark Yes. One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm not at all sure why this happens, but I suspect that a big part of it is concurrency issues within the kernel and filesystem. BUT - for most REAL applications that configuration is a lose. For example, for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) than one big box with a 4-way SMP system. Why? Because I get both better performance that way AND redundancy - if one box fails, I still have three more, all of which are working. If one box fails in a 4-way SMP configuration I have nothing at all. We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. I had an NT machine that ran file and print service for my office (before I sold the company). I replaced it with SAMBA on the same hardware. Performance more than doubled, and the ONLY thing that I changed was the operating system. Originally we were going to go with linux exclusively on this project, both because that's the only Intel unix my co-workers were familiar with, and based on recommendation from our proprietary CGI vendor. After weeks of soft soap I convinced my boss to use freebsd on one of the two boxes. Linux kicked our ass on the benchmarks for this program, mostly do to the "optimized idle loop" that was discussed here a couple of weeks ago. They beat us by 35% on the disk access/database tests, but I was able to get that down to only a 15% advantage if I went async. Fortunately my boss wasn't concerned about this test because the box is going to do 99% of its disk access over NFS, but... I told my boss (and he agreed completely) that benchmarks are not the same as real performance, so I was hoping to impress him with freebsd's stability and better performance in the real world application. And to a certain extent, I have, since when my box is running it's load average is consistently less than 1 while the linux box' load average is consistently over 5 with exactly the same number of requests. So, points for me on performance. However notice I said, "when my box is running." So far it's fallen down on NFS issues so many times that it's currently sidelined. The Linux box has been running for almost a week, and is currently handling the load for my box too. My boss has been patient, but he made the comment the other day that "so far freebsd is way ahead on the hassle factor" so I'm not sure that my part of the experiment is going to last much longer. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 07:27:42PM +0200, Nick Hibma wrote: The advantage of frequent reboots and patches is that at least you are up to date with security patches. :-) Security holes are rarely in the kernel, and you can easily keep your applications up-to-date without rebooting. -- Matthew Hunt [EMAIL PROTECTED] * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
I think it's been pretty well known since the beginning that FreeBSD SMP performance is nothing to cheer about. How does FreeBSD fare against NT or other systems on single processor systems? Sorry to follow up on my own message, but I noted today in PCWeek their trip back to the benchmark lab includes ripping 3 CPUs and 768M RAM out of the system, to benchmark how Linux and NT perform on "lower-end" hardware. They also allowed the RedHat dudes to switch to an Adaptec SCSI controller to talk to the RAID array. How are we holding up under this "diminished" configuration? We don't have any numbers for that yet, and we cheat a little (using a U2W controller and U2W external RAID unit). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the "one big kernel lock" problem and go to fine-grained locking. This is a non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. That's still a non-trivial task. :-) A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. I think mutex is the way to go. I am 100% for it, and I think now that this problem is getting a good deal of light we should start to do something about it. One of the problems with locks that doesn't seem to have been mentioned (although I am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: System unique identifier.....
From: Matthew Jacob [EMAIL PROTECTED] Date: 1999-06-24 15:03:56 -0700 To: [EMAIL PROTECTED] Subject: System unique identifier. Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.ORG I was talking about this on linux-kernel, but it also applies to *BSD... What're folks' motions of a settable system unique identifier, available prior to mountroot? This identifier has to be 64 bits or better and must be persistent across reboots. This could start a long discussion :-}. Some systems just take the IEEE MAC address from the motherboard, or that of the first interface it finds. Others use some algorithmic variation on that value, but it generally boils down to the same thing. For newer Intel boxes, you could just use the CPU chip... well, never mind. The main issue, I think, is that of persistence. How persistent do you want it? I'd bet that no matter what source you use, there's always the problem of "it broke; I had to replace it; now what?". Kind of like your grandfather's axe, which has had six handles and two blades over its lifetime, but it's still your grandfather's axe. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
synch primitives (was Re: Microsoft performance)
On Thu, 24 Jun 1999 20:14:19 CDT, Alfred Perlstein writes: I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. i'd really like to implement some of the basic solaris primitives: mutex, cv (condition variable), sema p/v. i sent a message to the smp list on this at one point but didn't get much of a response other than cranky noises about "super fine-grained locking isn't worth it". what i'd like to see is the groundwork laid for finER locking so that we can gradually break up the points of contention. mutex/cv/sema are intuitive and taught in every OS course; i don't feel "simple_lock" or "lockmgr" are desirable or adequate. i'm willing to work on it, but i can't get to it for at least a couple of months, so i'm hoping someone else wants to work on it too. aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. I meant something like an extensible set of mutex "groups", like our kernel malloc uses. New mutex types would be added. Instead of per- function mutexes, a single mutex "type" could be used for multiple functions that are the same in usage of sensitive resources. Just an idea... Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. Pardon the niaveness of this idea, but things like per-CPU malloc areas and each CPU haveing a queue for CPUs if memory is free'd by a processor that down't "own" it. Things like someone signalling another processor if one of its free queues becomes full, or if a CPU finds its pool exhausted. -Alfred Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Microsoft performance (was: ...)
Julian Elischer wrote: ok here are some of the problems.. Matt's changes allow dd to copy data at 2.5 times the rate it did before. I consider dd to be an application. The problem is due to resource handling in the kernel and results in large amounts of Idle CPU time. Another primary problem with the FreeBSD kernel (being addressed by Kirk) is that after writing a file, once the data has been queued for IO you cannot read the data in that file (even though it is present) until the IO is complete. With 64 tags, it is concievable that this could take a half second on a modern disk. These are problems shown up by the benchmarks but which can be shown to affect ordinary operations. There are other problems related to SMP and the GKL.. e.g.. two processes cannot access buffers at the same time, even though they are both present , because only one of them is allowed in the kernel at a time. Therefore One processor will spend a bunch of time at idle.. I think it's been pretty well known since the beginning that FreeBSD SMP performance is nothing to cheer about. How does FreeBSD fare against NT or other systems on single processor systems? I think we call consider SMP to be a work in progress. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NIS Question
[ This is probably better aimed at -questions, but seeing as I'm here... ] On Thu, Jun 24, 1999 at 12:13:53AM -0400, Nick LoPresti wrote: Here's my situation: 1. I would like to set up NIS on my network. 2. I have one FreeBSD system(2.2.6) 3. I have many other flavors of Unix on this network 4. I would like the FreeBSD system to export it's passwd and group files to the other machines How do I achieve this? Do I just run ypserv ypbind? Any FAQ's around??? Well, I've just been through the same problem (and spent around a day figuring out the answer...). Making your box a NIS server is easy. Just do grep -i nis /etc/defaults/rc.conf and plug the results into your /etc/rc.conf. You probably want to enable nis_server and yppasswdd. You probably also want to look at ypinit(8). The hard bit is making the other Unix hosts understand our password file. Beacuse we use MD5 encrypted passwords, instead of DES encrypted ones, they won't understand them by default. There's a couple of stages to this: 1) Install the DES routines. (easy) If you're still running -RELEASE, then try looking on your CD for the des packages. (harder) If you've moved up to -STABLE, then you'll need to cvsup the secure-all stuff and rebuild the world. When you've done that, you need to repoint the /usr/lib/libcrypt* symlinks to point at libdescrypt* instead of libscrypt*. That last step took a while to figure out. :-) 2) You need to set the UNSECURE variable in /var/yp/Makefile. Most of this stuff is documented in the various manpages for yp... One final word of warning. You'd be best off not distributing your root password over nis. In fact, Sun reccomends that when setting up a nis server, you keep a separate copy of the passwd file, without system users in it. This will make sharing the pasword file easier across multiple vendors. You may want to look at the Sun Answerbooks for some more tips and ideas: http://docs.sun.com/ -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator Always think very hard before messing with TCP. And then don't. -- MC -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
Sheldon Hearn wrote: I used to pride myself in my communication skills, but I'm starting to doubt myself. :-) It's not that we don't understand you, it's that we don't agree with you. There is a HUGE difference. My concern is that what you want introduces duplicate functionality. You keep saying, but you can do something like what you want to do with tcp wrappers, but others are saying, quite clearly that they want to be able to COMPLETELY bypass tcp_wrappers altogether. Configuring tcp_wrappers for a specific case is very different from not having to configure it at all. 1) Performance. I think we're all clear now that exclusion options will not introduce a significant performance gain. We've already scored our performance gain by obviating an exec on tcpd. By excluding tcp_wrappers you're also excluding the overhead to check the hosts.allow file. On a heavily loaded service this can be considerable. It's critical that folks understand that built-in wrapping in inetd is not the same as inetd passing the job of wrapping to a program called tcpd. Something different is happening in each case. It just so happens that the two cases share a common goal. Actually, the same thing is happening, just in different places. When you say you want functionality that exists with TCP wrappers, I think you mean identical semantics to those used with tcpd. You can't have it, it's that simple. As long as you acknowledge that in this case, You can't have it is a design decision, and not everyone agrees with your concept of the design. Personally I don't care enough about it to write the patch, but that won't stop me from registering an objection since you seem to be assuming that silence == assent. What you should be able to have is the same functionality as was available when using tcpd. I don't think the fact that you may need to set things up differently to achieve the same results as you had before isn't a serious problem, because you're doing a different thing now. That's because you're looking at this from the standpoint of a developer who is deeply involved in the code on a daily basis. You need to start thinking of things in terms of the much more common case, the casual user who will be going from say, 3.0-Release to 3.3-Release without reading any of the documentation. Why should this user have to either go out of his way to fix something that wasn't broken, or find a critical service disabled when he reboots just because no one could be bothered to make the new interface compatible? As far as I'm concerned the system should ship with per service toggles, and all of them toggled off, with a hosts.allow with nothing but ALL : ALL in it. But then again I've been called overcautious. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Thu, 24 Jun 1999 01:53:32 MST, Doug wrote: As long as you acknowledge that in this case, You can't have it is a design decision, and not everyone agrees with your concept of the design. Personally I don't care enough about it to write the patch, but that won't stop me from registering an objection since you seem to be assuming that silence == assent. You're right. If I make my intentions publically known and nobody objects, I assume public agreement. So I acknowledge that we're involved in design decisions here. You need to start thinking of things in terms of the much more common case, the casual user who will be going from say, 3.0-Release to 3.3-Release without reading any of the documentation. You're making assumptions about what I'm trying to achieve. I'm quite sensitive to upgrade issues. Why should this user have to either go out of his way to fix something that wasn't broken, or find a critical service disabled when he reboots just because no one could be bothered to make the new interface compatible? Okay, this is what makes sense. :-) I do agree that it should be as easy as possible to upgrade from 3.2-RELEASE to 3.3-RELEASE. What you need to see is that such an upgrade _will_ involve changing some things, which is why we offer people release notes. What we're discussing (and have up until now disagreed on) is how much has to change. Since none of the people who've suggested per-case exclusion options for wrapping have come up with diffs, it's something I'll have to think about. If I can come up with something backward compatible without rupturing a testicle, I'll do so. Watch this space for details. :-) Cia, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
sysinstall hacking - urgent
I currently use sysinstall with the install.cfg configuration file for an automatic installation. I need to make sysinstall formating only a small FreeBSD partition of the disk and not the whole disk, or the free space. I already have a function that give me the size of the partition that I need to format. I would just like to choose the offset and the size for create_chunk(). The file that interest me is disks.c, in /usr/src/release/sysinstall, at the end, there is the all and free options... I would like to create another option, added to all and free, says custom where I could specify the offset and the size. The problem is that I can't do this by taking some parts of free option code, because it doesn't seem to work (unable to find X slice or something like that, X is set in create_chunk.c, see later) Can anybody give me the structure of a whole disk accorded to sysinstall? with chunk structures, ... Or if someone know how to implement this, I would be glad to heard about it... (I think that I could take the code of free option a little bit modified) Others useful files are /usr/src/lib/libdisk/ create_chunk.c and chunk.c Thanks! Sebastien MARAUX To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
Wes Peters wrote: Julian Elischer wrote: ok here are some of the problems.. Matt's changes allow dd to copy data at 2.5 times the rate it did before. I consider dd to be an application. The problem is due to resource handling in the kernel and results in large amounts of Idle CPU time. Another primary problem with the FreeBSD kernel (being addressed by Kirk) is that after writing a file, once the data has been queued for IO you cannot read the data in that file (even though it is present) until the IO is complete. With 64 tags, it is concievable that this could take a half second on a modern disk. These are problems shown up by the benchmarks but which can be shown to affect ordinary operations. There are other problems related to SMP and the GKL.. e.g.. two processes cannot access buffers at the same time, even though they are both present , because only one of them is allowed in the kernel at a time. Therefore One processor will spend a bunch of time at idle.. I think it's been pretty well known since the beginning that FreeBSD SMP performance is nothing to cheer about. How does FreeBSD fare against NT or other systems on single processor systems? Sorry to follow up on my own message, but I noted today in PCWeek their trip back to the benchmark lab includes ripping 3 CPUs and 768M RAM out of the system, to benchmark how Linux and NT perform on lower-end hardware. They also allowed the RedHat dudes to switch to an Adaptec SCSI controller to talk to the RAID array. How are we holding up under this diminished configuration? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote: Karl Denninger wrote: I've found FreeBSD to outperform NT-anything in any task you throw at the machine from web service to Samba for file and print service for PCs running Windows. Granted. Perhaps we're seeing an artifact of NT's developers focussing on optimizing their system for good benchmark performance rather than good real-world performance. 'twill be interesting to see the offical report to find out where the various strengths and weaknesses really are. - mark Yes. One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm not at all sure why this happens, but I suspect that a big part of it is concurrency issues within the kernel and filesystem. BUT - for most REAL applications that configuration is a lose. For example, for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) than one big box with a 4-way SMP system. Why? Because I get both better performance that way AND redundancy - if one box fails, I still have three more, all of which are working. If one box fails in a 4-way SMP configuration I have nothing at all. Now there ARE monolithic applications that don't take well to that kind of scaling - big DBMS servers, for example. But DBMS servers are typically I/O bound anyway, not CPU bound (there are exceptions, yes, but the general rule is that they are RAM and disk bound). I had an NT machine that ran file and print service for my office (before I sold the company). I replaced it with SAMBA on the same hardware. Performance more than doubled, and the ONLY thing that I changed was the operating system. That's but one real-world example out of many. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Wed, Jun 23, 1999 at 08:48:54PM -0700, Julian Elischer wrote: With Uniprocessor things are a lot more equal. but we still suck on netbench. This is due to the exact form of netbench which is exactly nonoptimal for FreeBSD. I'm not interested in benchmarks. I'm interested in real-world performance and real-world operational work done over units of time. Also becaosue of the GKL (Giant Kernel Lock) (see Solaris's results) I know about the SMP issues. But in many applications going to SMP is actually a reliability AND throughput lose (web servers is one example). You're better off with 4 machines than 1 big 4-way machine. So don't assume that NT figures must be bad.. we have too many weaknesses in our own code to throw stones. It'd be intersting to see how FreeBSD 1.1.5 would have performed on the same tests. Sometimes we've gained in general performance but lost in some specific cases. Anyone can tune a kernel or OS for benchmarks. I'm a lot more interested in how it all works in the real world since you don't run benchmarks when you're trying to get real work done. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
Wes Peters w...@softweyr.com wrote: Sorry to follow up on my own message, but I noted today in PCWeek their trip back to the benchmark lab includes ripping 3 CPUs and 768M RAM out of the system, to benchmark how Linux and NT perform on lower-end hardware. They also allowed the RedHat dudes to switch to an Adaptec SCSI controller to talk to the RAID array. How are we holding up under this diminished configuration? It's stupid to tune everything for performance except for the web server -- they should be using Zeus, not Apache. Tony. -- f.a.n.finch d...@dotat.at f...@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 10:00:41AM -0500, Karl Denninger wrote: I know about the SMP issues. But in many applications going to SMP is actually a reliability AND throughput lose (web servers is one example). You're better off with 4 machines than 1 big 4-way machine. The problem is that a loaded 2-way machine is only slightly more expensive than a 1-way, and current trends indicate that 4-ways will be increasingly common. It isn't a question of 1 big 4-way vs 4 1-ways, but of what you can get of out $Xk worth of hardware. The current sweet spot is often some number of 2-ways, and if for your app the OS doesn't scale it can make that OS less economical by comparison. john -- John Bradley Plevyak,PhD,jplev...@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 310, San Mateo, CA 94403 W:(650)653-2830 F:(650)653-2889 P:(888)491-1332/5103192436.4911...@pagenet.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Beating system usage down
Greetings, A machine that I hold very close under my wing has been very contently chugging along for the last few months with practically no idle processor. However, I noticed that the CPUs are spinning a lot of cycles in the system area. CPU states: 5.5% user, 0.0% nice, 88.9% system, 4.0% interrupt, 1.6% idle First, some background. The machine is a Dual P2-450 with 1GB of RAM. It runs apache, and currently handles 90 hits a second, with each of those hits spawning various CGIs (one per hit) that completes in under a second. My first theory was that the kernel was uselessly spinning in various record locks via fcntl(). However, as a test I removed all file locking from the various CGIs and noticed no change in the system usage. My second theory was the overhead with the SMP code. So, I removed it from the kernel and ran a single CPU box for a few minutes. The system usage went down to around 60%, but the system was noticeably slower. Any ideas? Regards, Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
weird socket behaviour (sbflush)...
Hi, while implementing a reliable datagram protocol (PGM for what matters) i am hitting a weird behaviour of sbflush(). The problem is, the protocol (at least, in my implementation) allows the writing of zero-sized packets (essentially, just headers and no payload) which are put in the socket buffer. This results in some cases in sb_cc = 0, sb_mbcnt != 0, and this condition causes sbflush to panic. There is not an equivalent of this in TCP (which counts bytes, not segments) or UDP (which allows zero-sized packets but bypasses the socket buffer) so i am not sure if it is appropriate to fix sbflush() so that it uses sbdroprecord() instead of sbdrop() in case of a datagram protocol ? cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3.x NFS patchset
Hi Julian, I was trying out your patches 'nfs-3.diffs'. However, I think I have the wrong version (3.2-RELASE) of the original sources (1 Hunk in nfs_serv.c failed). Could you tell me which is the correct version of the sources to patch? I'd just love to see NFS work at boot time :-) best regards Jan -- Physikalisches Institut der Universitaet Bonn Nussallee 12 D-53115 Bonn GERMANY To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote: I've found FreeBSD to outperform NT-anything in any task you throw at the machine from web service to Samba for file and print service for PCs running Windows. Granted. Perhaps we're seeing an artifact of NT's developers focussing on optimizing their system for good benchmark performance rather than good real-world performance. 'twill be interesting to see the offical report to find out where the various strengths and weaknesses really are. The weaknesses are obvious and well documented by Microsoft itself. We have a customer that insisted on using NT for its webserver. Yesterday we had trouble with the time stamp in the logs. It simply stopped at a specific time. After that the timestamp was all the same. The problem was: http://support.microsoft.com/support/kb/articles/q223/1/37.asp This problem can occur if the server runs for more than 49 days without being restarted planck(1:327) $ uname -a FreeBSD planck 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE #0: Mon Jun 23 16:49:02 CEST 1997 root:/usr/src/sys/compile/CHDKERNEL i386 planck(1:328) $ uptime 6:39PM up 590 days, 22:04, 3 users, load averages: 0.01, 0.08, 0.07 *** This server is NOT idling, it's acting (besides other things) as a radius server servering some thousand dialins. Do you need any other arguments? \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:maex-...@space.net | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
The advantage of frequent reboots and patches is that at least you are up to date with security patches. :-) Nick planck(1:327) $ uname -a FreeBSD planck 2.2.1-RELEASE FreeBSD 2.2.1-RELEASE #0: Mon Jun 23 16:49:02 CEST 1997 root:/usr/src/sys/compile/CHDKERNEL i386 planck(1:328) $ uptime 6:39PM up 590 days, 22:04, 3 users, load averages: 0.01, 0.08, 0.07 *** This server is NOT idling, it's acting (besides other things) as a radius server servering some thousand dialins. Do you need any other arguments? \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:maex-...@space.net | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
The advantage of frequent reboots and patches is that at least you are up to date with security patches. :-) LKM/KLD might help here... with the kernel of your kernel being essentially a linker :) cheers luigi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
In the tests they used both Zeus AND Apache On Thu, 24 Jun 1999, Tony Finch wrote: Wes Peters w...@softweyr.com wrote: Sorry to follow up on my own message, but I noted today in PCWeek their trip back to the benchmark lab includes ripping 3 CPUs and 768M RAM out of the system, to benchmark how Linux and NT perform on lower-end hardware. They also allowed the RedHat dudes to switch to an Adaptec SCSI controller to talk to the RAID array. How are we holding up under this diminished configuration? It's stupid to tune everything for performance except for the web server -- they should be using Zeus, not Apache. Tony. -- f.a.n.finch d...@dotat.at f...@demon.net Winner, International Obfuscated C Code Competition 1998 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 01:23:19PM +0930, Mark Newton wrote: Karl Denninger wrote: I've found FreeBSD to outperform NT-anything in any task you throw at the machine from web service to Samba for file and print service for PCs running Windows. Granted. Perhaps we're seeing an artifact of NT's developers focussing on optimizing their system for good benchmark performance rather than good real-world performance. 'twill be interesting to see the offical report to find out where the various strengths and weaknesses really are. - mark Yes. One place where we *ARE* weak is N-way (more than 2-way) SMP systems. I'm not at all sure why this happens, but I suspect that a big part of it is concurrency issues within the kernel and filesystem. BUT - for most REAL applications that configuration is a lose. For example, for a big web server I'd prefer 4 boxes and 4 IP addresses (round-robin) than one big box with a 4-way SMP system. Why? Because I get both better performance that way AND redundancy - if one box fails, I still have three more, all of which are working. If one box fails in a 4-way SMP configuration I have nothing at all. We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. I had an NT machine that ran file and print service for my office (before I sold the company). I replaced it with SAMBA on the same hardware. Performance more than doubled, and the ONLY thing that I changed was the operating system. Originally we were going to go with linux exclusively on this project, both because that's the only Intel unix my co-workers were familiar with, and based on recommendation from our proprietary CGI vendor. After weeks of soft soap I convinced my boss to use freebsd on one of the two boxes. Linux kicked our ass on the benchmarks for this program, mostly do to the optimized idle loop that was discussed here a couple of weeks ago. They beat us by 35% on the disk access/database tests, but I was able to get that down to only a 15% advantage if I went async. Fortunately my boss wasn't concerned about this test because the box is going to do 99% of its disk access over NFS, but... I told my boss (and he agreed completely) that benchmarks are not the same as real performance, so I was hoping to impress him with freebsd's stability and better performance in the real world application. And to a certain extent, I have, since when my box is running it's load average is consistently less than 1 while the linux box' load average is consistently over 5 with exactly the same number of requests. So, points for me on performance. However notice I said, when my box is running. So far it's fallen down on NFS issues so many times that it's currently sidelined. The Linux box has been running for almost a week, and is currently handling the load for my box too. My boss has been patient, but he made the comment the other day that so far freebsd is way ahead on the hassle factor so I'm not sure that my part of the experiment is going to last much longer. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the one big kernel lock problem and go to fine-grained locking. This is a non-trivial job. I had an NT machine that ran file and print service for my office (before I sold the company). I replaced it with SAMBA on the same hardware. Performance more than doubled, and the ONLY thing that I changed was the operating system. . However notice I said, when my box is running. So far it's fallen down on NFS issues so many times that it's currently sidelined. What release are you running? There ARE NFS issues - most of which can be solved. I had to do this all the time running an ISP with a home-grown cluster system that did exactly that - all real data was sitting on a couple of big RAID arrays - and served via NFS. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. That's the world I lived in (except that I used FreeBSD for the NFS servers as well!) and done properly it works EXTREMELY well. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
I certainly hope you have applied the recent NFS patches. That should solve your problem. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the one big kernel lock problem and go to fine-grained locking. This is a non-trivial job. No argument there. My point was more in support of the people who were demonstrating how other platforms are kicking our ass. Responding with, Yeah, but if you limit yourself to the specific case where freebsd performs well, we rock! doesn't cut it. However notice I said, when my box is running. So far it's fallen down on NFS issues so many times that it's currently sidelined. What release are you running? Started with 3.2-Stable, moved to -Current to get the latest and greatest NFS fixes, the problem is that most of the fixes are for the server, and my box is an amd/nfs client connecting to sun (almost all 2.6) servers. I've posted rather voluminously on this topic to both -current and -hackers over the past two weeks, but I've stopped doing that because I have nothing new and I haven't gotten any responses in a while. I just checked the archives and a search on those two lists for heavily and loaded and amd brings up the threads. I'm actually building world right now to get the latest NFS patch just in case it helps, but I'm not sure how much longer we (my department) can justfiy the expense of me fiddling around with this because we already know that the linux box works. Now if we were talking about a uni-processor system doing nothing but serving web pages from local disk, I know I'd be kicking some serious ass, but that model isn't the real world anymore. Especially as Network Appliance boxes become more and more common (and they will be, fast and furious) multi-processor and NFS are for all practical purposes already the reality now, and will only be more so in the future. That's the world I lived in (except that I used FreeBSD for the NFS servers as well!) and done properly it works EXTREMELY well. I'm not going to have that luxury, and I really believe that NetApp and it's cousings are going to be THE point of access in the next year or so. They work too well to pass up, and now that they are OEM'ing the disk shelves they will be too cheap to justify rolling your own for all but the most diehard platform advocates. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the one big kernel lock problem and go to fine-grained locking. This is a non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 07:27:42PM +0200, Nick Hibma wrote: The advantage of frequent reboots and patches is that at least you are up to date with security patches. :-) Security holes are rarely in the kernel, and you can easily keep your applications up-to-date without rebooting. -- Matthew Hunt m...@astro.caltech.edu * Inertia is a property http://www.pobox.com/~mph/ * of matter. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
I think it's been pretty well known since the beginning that FreeBSD SMP performance is nothing to cheer about. How does FreeBSD fare against NT or other systems on single processor systems? Sorry to follow up on my own message, but I noted today in PCWeek their trip back to the benchmark lab includes ripping 3 CPUs and 768M RAM out of the system, to benchmark how Linux and NT perform on lower-end hardware. They also allowed the RedHat dudes to switch to an Adaptec SCSI controller to talk to the RAID array. How are we holding up under this diminished configuration? We don't have any numbers for that yet, and we cheat a little (using a U2W controller and U2W external RAID unit). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
Wes Peters w...@softweyr.com wrote: Sorry to follow up on my own message, but I noted today in PCWeek their trip back to the benchmark lab includes ripping 3 CPUs and 768M RAM out of the system, to benchmark how Linux and NT perform on lower-end hardware. They also allowed the RedHat dudes to switch to an Adaptec SCSI controller to talk to the RAID array. How are we holding up under this diminished configuration? It's stupid to tune everything for performance except for the web server -- they should be using Zeus, not Apache. The Zeus evaluation license prohibits its use for benchmarks, and the Zeus folks failed to respond to any of my attempts to communicate. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Beating system usage down
Just for those that have been following the benchmarking thread, this is exactly the same symptom set that FreeBSD demonstrates when loaded by WebBench. The gotcha here is, again, the giant kernel lock. Greetings, A machine that I hold very close under my wing has been very contently chugging along for the last few months with practically no idle processor. However, I noticed that the CPUs are spinning a lot of cycles in the system area. CPU states: 5.5% user, 0.0% nice, 88.9% system, 4.0% interrupt, 1.6% idle First, some background. The machine is a Dual P2-450 with 1GB of RAM. It runs apache, and currently handles 90 hits a second, with each of those hits spawning various CGIs (one per hit) that completes in under a second. My first theory was that the kernel was uselessly spinning in various record locks via fcntl(). However, as a test I removed all file locking from the various CGIs and noticed no change in the system usage. My second theory was the overhead with the SMP code. So, I removed it from the kernel and ran a single CPU box for a few minutes. The system usage went down to around 60%, but the system was noticeably slower. Any ideas? Regards, Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the one big kernel lock problem and go to fine-grained locking. This is a non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. In my neck of the woods (doing lots of multi-threaded stuff), that is the definition of 'fine-grained' locks, vs. 'coarse-grained' locks. What we have now is a big 'coarse-grained' lock. :) Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 11:14:24AM -0700, Doug wrote: That's the world I lived in (except that I used FreeBSD for the NFS servers as well!) and done properly it works EXTREMELY well. I'm not going to have that luxury, and I really believe that NetApp and it's cousings are going to be THE point of access in the next year or so. They work too well to pass up, and now that they are OEM'ing the disk shelves they will be too cheap to justify rolling your own for all but the most diehard platform advocates. The point I was making, Doug, is that FreeBSD as an NFS client works quite well in my experience, PROVIDED that you are (1) running a good code base, and (2) have things set up correctly. I don't argue with the Netapp people; they have a good product that does a good job. The major problme has been the disk cost for a long time; if they're fixing that, then the overall picture will change dramatically and in their favor, which is a good thing. However, that doesn't change the fact that FreeBSD makes quite a good NFS client IF you do things right. Yes, there are issues. No, they're not impossible to solve. -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the one big kernel lock problem and go to fine-grained locking. This is a non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. That's still a non-trivial task. :-) -- -- Karl Denninger (k...@denninger.net) Web: fathers.denninger.net I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: We're adding some machines at work for (essentially) cgi processing only. It was never considered to use anything less than 2 cpu boxes, and the current round of testing is going so well that we're seriously considering 4 cpu boxes because they are not that much more expensive and our processing is highly CPU bound. I agree that redundancy is a good thing, but at some point the increased network latency exceends the point of diminishing returns for the redundancy factor. In short, increasing SMP efficiency should really be a priority for N2 systems. Agreed. But this is a BIG job, because to do that you have to solve the one big kernel lock problem and go to fine-grained locking. This is a non-trivial job. We don't need fine-grained locks. We would get good performance if we could get (say) per-subsystem locks. That's still a non-trivial task. :-) A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: CDROM drive doesn't probe if no CD present [Was:cannot mount cd indicates bad ide cd drive - replace?]
Re: what brand/model is it? US Drives 40x Model:USDRIVES 24DT -Original Message- From: Doug White [mailto:dwh...@resnet.uoregon.edu] Sent: Tuesday, June 22, 1999 12:45 PM To: Woody Carey Cc: 'freebsd-questi...@freebsd.org'; hack...@freebsd.org Subject: RE: CDROM drive doesn't probe if no CD present [Was:cannot mount cd indicates bad ide cd drive - replace?] I'm lofting this up on -hackers to get the attention of the ATAPI CD driver programmer -- Soren, you still around? Take a look at this. On Tue, 22 Jun 1999, Woody Carey wrote: Ok, here is some more information: Here is the behavior when there is no cd in the drive at bootup [reboot, actually] ^M^[[Kmyname# mount /cdrom cd9660: Input/output error myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 0 - 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked and here is the dmesg output and mount output with a cd in the drive at boot: myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked myname# mount /cdrom There was some success message on the console after this mount indicating success. It did not appear in this script output, obviously. Bizarre. That may be a driver bug or your drive is getting into an inconsistent state if it doesn't boot with a CD present. What brand/model of CD drive is it? Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. I think mutex is the way to go. I am 100% for it, and I think now that this problem is getting a good deal of light we should start to do something about it. One of the problems with locks that doesn't seem to have been mentioned (although I am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
System unique identifier.....
I was talking about this on linux-kernel, but it also applies to *BSD... What're folks' motions of a settable system unique identifier, available prior to mountroot? This identifier has to be 64 bits or better and must be persistent across reboots. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: System unique identifier.....
From: Matthew Jacob mja...@feral.com Date: 1999-06-24 15:03:56 -0700 To: freebsd-hackers@FreeBSD.ORG Subject: System unique identifier. Delivered-to: freebsd-hackers@freebsd.org X-Loop: FreeBSD.ORG I was talking about this on linux-kernel, but it also applies to *BSD... What're folks' motions of a settable system unique identifier, available prior to mountroot? This identifier has to be 64 bits or better and must be persistent across reboots. This could start a long discussion :-}. Some systems just take the IEEE MAC address from the motherboard, or that of the first interface it finds. Others use some algorithmic variation on that value, but it generally boils down to the same thing. For newer Intel boxes, you could just use the CPU chip... well, never mind. The main issue, I think, is that of persistence. How persistent do you want it? I'd bet that no matter what source you use, there's always the problem of it broke; I had to replace it; now what?. Kind of like your grandfather's axe, which has had six handles and two blades over its lifetime, but it's still your grandfather's axe. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: System unique identifier.....
Some systems just take the IEEE MAC address from the motherboard, or that of the first interface it finds. Others use some algorithmic variation on that value, but it generally boils down to the same thing. For newer Intel boxes, you could just use the CPU chip... well, never mind. Yes. The Solaris drivers use the 'localetheraddr' function, or's in 160 and then HBA instance # 48 to make a NAA_IEEE port identifier. The main issue, I think, is that of persistence. How persistent do you want it? I'd bet that no matter what source you use, there's always the problem of it broke; I had to replace it; now what?. Kind of like your grandfather's axe, which has had six handles and two blades over its lifetime, but it's still your grandfather's axe. I want it to persist until it's changed. Change doesn't mean a reboot. The practical side of this problem, which is a relatively trivial problem, is to supply a consistent node WWN for fibre channel adapters that don't have an assigned WWN in NVRAM. This only needs to be persistent across reboots when I finish implementing the target mode code- a WWN identifying a system as a 'device' needs to persist until told to change. There's all sorts of good stuff for generating 128 UUIDs. That has multiple uses. I want it to be availble to the kernel, and that prior to reboot. It strikes me that some userland generation of UUID could be used to seed a particular kernel- which could be changed via sysctl as needed (w/o rebooting). I'm trying to think of the practical and least objectionable semantics of how to support that sooner rather than later. The Linux folks (mostly Ted) helped me clarify some thinking about this so that the basic original source of the seeded WWN doesn't have to come from first principles in hardware that can be read prior to mounting root. But where the linux folks aren't really hipped on is a good architecturally clean place to store the seed. It'd be nice if we thought of this for FreeBSD. -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On 24-Jun-99 Sheldon Hearn wrote:
On Thu, 24 Jun 1999 01:53:32 MST, Doug wrote:
As long as you acknowledge that in this case, You can't have it is a
design decision, and not everyone agrees with your concept of the design.
Personally I don't care enough about it to write the patch, but that won't
stop me from registering an objection since you seem to be assuming that
silence == assent.
You're right. If I make my intentions publically known and nobody
objects, I assume public agreement. So I acknowledge that we're involved
in design decisions here.
You need to start thinking of things in terms of the much more common
case, the casual user who will be going from say, 3.0-Release to
3.3-Release without reading any of the documentation.
You're making assumptions about what I'm trying to achieve. I'm quite
sensitive to upgrade issues.
Why should this user have to either go out of his way to fix something
that wasn't broken, or find a critical service disabled when he
reboots just because no one could be bothered to make the new
interface compatible?
Okay, this is what makes sense. :-)
I do agree that it should be as easy as possible to upgrade from
3.2-RELEASE to 3.3-RELEASE. What you need to see is that such an upgrade
_will_ involve changing some things, which is why we offer people
release notes. What we're discussing (and have up until now disagreed
on) is how much has to change.
Since none of the people who've suggested per-case exclusion options
for wrapping have come up with diffs, it's something I'll have to think
about. If I can come up with something backward compatible without
rupturing a testicle, I'll do so.
Watch this space for details. :-)
Ok. since you asked:
Here's one possibility, it adds a a wrap/nowrap field that goes beside the
wait/nowait field, so you would have:
ftp stream tcp nowait wrap root /usr/libexec/ftpd ftpd -l
as an example of ftp being wrapped. here's the patch to inetd.c (against
-stable, which is all I have at the moment):
Index: inetd.c
===
RCS file: /usr/cvs/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.46.2.2
diff -u -r1.46.2.2 inetd.c
--- inetd.c 1999/05/12 07:02:02 1.46.2.2
+++ inetd.c 1999/06/24 23:36:24
@@ -73,6 +73,7 @@
* socket type stream/dgram/raw/rdm/seqpacket
* protocolmust be in /etc/protocols
* wait/nowait single-threaded/multi-threaded
+ * wrap/nowrap wrapped or not
* useruser to run daemon as
* server program full path name
* server program argumentsmaximum of MAXARGS (20)
@@ -97,6 +98,7 @@
* socket type stream/dgram/raw/rdm/seqpacket
* protocolmust be in /etc/protocols
* wait/nowait single-threaded/multi-threaded
+ * wrap/nowrap wrapped or not
* useruser to run daemon as
* server program full path name
* server program argumentsmaximum of MAXARGS
@@ -215,6 +217,9 @@
u_char se_type;/* type: normal, mux, or mux+ */
u_char se_checked; /* looked at during merge */
u_char se_accept; /* i.e., wait/nowait mode */
+#ifdef LIBWRAP_INTERNAL
+u_char se_wrap;/* wrap/nowrap mode */
+#endif
u_char se_rpc; /* ==1 if RPC service */
int se_rpc_prog;/* RPC program number */
u_int se_rpc_lowvers; /* RPC low version */
@@ -621,6 +626,8 @@
#ifdef LIBWRAP
#ifndef LIBWRAP_INTERNAL
if (sep-se_bi == 0)
+#else
+if (sep-se_wrap)
#endif
if (sep-se_accept
sep-se_socktype == SOCK_STREAM) {
@@ -905,6 +912,9 @@
}
}
sep-se_accept = new-se_accept;
+#ifdef LIBWRAP_INTERNAL
+ sep-se_wrap = new-se_wrap;
+#endif
SWAP(sep-se_user, new-se_user);
SWAP(sep-se_group, new-se_group);
#ifdef LOGIN_CAP
@@ -1377,6 +1387,19 @@
goto more;
}
}
+#ifdef LIBWRAP_INTERNAL
+ arg = sskip(cp);
+ if (!strncmp(arg, wrap, 4))
+ sep-se_wrap = 1;
+else if (!strncmp(arg, nowrap, 6))
+sep-se_wrap = 0;
+else {
+syslog(LOG_ERR,
+%s: bad wrap/nowrap for services %s,
+ CONFIG, sep-se_service);
+ goto more;
+ }
+#endif
sep-se_user = newstr(sskip(cp));
#ifdef LOGIN_CAP
if ((s =
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, David E. Cross wrote: I think mutex is the way to go. I am 100% for it, and I think now that this problem is getting a good deal of light we should start to do something about it. One of the problems with locks that doesn't seem to have been mentioned (although I am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. Did you forget the fact that in order to remove a giant lock set up, so that you go one step, or multiple steps, below that, the locks below the giant lock must ALL be there, no mistakes or omissions allowed. It's well worth doing, but it's not a deal like adding just one lock, no sir! +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, David E. Cross wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. I think mutex is the way to go. I am 100% for it, and I think now that this problem is getting a good deal of light we should start to do something about it. One of the problems with locks that doesn't seem to have been mentioned (although I am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. Exactly, there are complex problems to deal with with locking certain structures even in the UP model (when to raise spl() and such) My point is that if someone with the experiance defined protocols for locking each subsystem we definetly have enough people to implement it eventually. If the stupbs for this were in place it would motivate people to work on it. -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. Pardon the niaveness of this idea, but things like per-CPU malloc areas and each CPU haveing a queue for CPUs if memory is free'd by a processor that down't own it. Things like someone signalling another processor if one of its free queues becomes full, or if a CPU finds its pool exhausted. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
synch primitives (was Re: Microsoft performance)
On Thu, 24 Jun 1999 20:14:19 CDT, Alfred Perlstein writes: I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. i'd really like to implement some of the basic solaris primitives: mutex, cv (condition variable), sema p/v. i sent a message to the smp list on this at one point but didn't get much of a response other than cranky noises about super fine-grained locking isn't worth it. what i'd like to see is the groundwork laid for finER locking so that we can gradually break up the points of contention. mutex/cv/sema are intuitive and taught in every OS course; i don't feel simple_lock or lockmgr are desirable or adequate. i'm willing to work on it, but i can't get to it for at least a couple of months, so i'm hoping someone else wants to work on it too. aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Brian F. Feldman wrote: On Thu, 24 Jun 1999, Alfred Perlstein wrote: On Thu, 24 Jun 1999, Karl Denninger wrote: A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. Hey, y'know getppid() is safe, i'll just take the lock out. this function xxx() is safe until this point I can process a lot before actually needing this lock... y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here if I just do this something here, I really am re-entrant and safe.. Providing a simple api for spinlocks and mutexes would be very nice. Something along the lines of how spl()s work? And mutex allocation like what we do with malloc types, maybe? I'm not sure what you mean by the refernce to malloc types, I just thought something along the lines of mutex_t with an API for trying, allocating, freeing and initializing them. I meant something like an extensible set of mutex groups, like our kernel malloc uses. New mutex types would be added. Instead of per- function mutexes, a single mutex type could be used for multiple functions that are the same in usage of sensitive resources. Just an idea... Also, some really interesting things could be done via per-CPU resource pools to lower the amount of contention on objects. Pardon the niaveness of this idea, but things like per-CPU malloc areas and each CPU haveing a queue for CPUs if memory is free'd by a processor that down't own it. Things like someone signalling another processor if one of its free queues becomes full, or if a CPU finds its pool exhausted. -Alfred Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Anybody using the Efficient Networks ATM PCI adapter?
I see it's supported, but I'm curious if anybody is using it. If so, I'd like to ask a few questions off-line of somebody... Thanks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Thu, 24 Jun 1999, Alfred Perlstein wrote: Pardon the niaveness of this idea, but things like per-CPU malloc areas and each CPU haveing a queue for CPUs if memory is free'd by a processor that down't own it. Things like someone signalling another processor if one of its free queues becomes full, or if a CPU finds its pool exhausted. This sounds a lot like local resource management in a distributed locking system (the local lock manager obtains covering locks on a pool of resources and can manage those locally, but can relinquish the locks to another lock manager when requested if it is holding them but not actually using them). Concurrency theory interests me, but I don't have the resources (heh, heh) to be useful at the moment. Kris -Alfred Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message - Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes. -- Unknown To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
On Fri, 25 Jun 1999, Kris Kennaway wrote: On Thu, 24 Jun 1999, Alfred Perlstein wrote: Pardon the niaveness of this idea, but things like per-CPU malloc areas and each CPU haveing a queue for CPUs if memory is free'd by a processor that down't own it. Things like someone signalling another processor if one of its free queues becomes full, or if a CPU finds its pool exhausted. This sounds a lot like local resource management in a distributed locking system (the local lock manager obtains covering locks on a pool of resources and can manage those locally, but can relinquish the locks to another lock manager when requested if it is holding them but not actually using them). Concurrency theory interests me, but I don't have the resources (heh, heh) to be useful at the moment. Theoretically you can simulate an SMP enviorment by removing the run to completion way that the kernel works, basically in UP while the kernel is working, it can't be interupted. By removing that restriction and at the same time putting up boundries on all syscalls to push that down you can pretty much simulate the effect of SMP. The farther you push the barriers down in the codepaths the better things get, with the eventual hope of removing them almost entirely. Right now most kernel utility functions would also need to grab the status of the lock and push it down then restore it apon return. This way malloc and friends can be considered safe. btw, am I using the word codepath correctly? is it even a word? :) -Alfred Perlstein - [bri...@rush.net|bri...@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: System unique identifier.....
On Thu, 24 Jun 1999 15:02:25 -0700 (PDT) Matthew Jacob mja...@feral.com wrote: I was talking about this on linux-kernel, but it also applies to *BSD... What're folks' motions of a settable system unique identifier, available prior to mountroot? This identifier has to be 64 bits or better and must be persistent across reboots. ...to be used for...? -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Microsoft performance (was: ...)
Alan Cox has just started passing around some code that starts on the breakdown of the GKL I suggest that all intersted parties go to the SMP list if they wish to take part in this action. On Thu, 24 Jun 1999, Chuck Robey wrote: On Thu, 24 Jun 1999, David E. Cross wrote: I think mutex is the way to go. I am 100% for it, and I think now that this problem is getting a good deal of light we should start to do something about it. One of the problems with locks that doesn't seem to have been mentioned (although I am sure many have thought it) is deadlocks. You get A waiting for B and b with A. With mutexi (plural?) you would lock just the resource that you are curently working on, and you would be guaranteed to release it (if the programmers do it right, of course ;). The advantage is with Mutex is that you don't need to be as omnipotent to use it. Did you forget the fact that in order to remove a giant lock set up, so that you go one step, or multiple steps, below that, the locks below the giant lock must ALL be there, no mistakes or omissions allowed. It's well worth doing, but it's not a deal like adding just one lock, no sir! +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
