Re: The Trolls identity (was: Re: matthew dillon)
On Sun, 9 Feb 2003, Rahul Siddharthan wrote: (I assume I'm replying to the real PHK here) [EMAIL PROTECTED] wrote: We know that the lamer behind the Troll is Bill Huey aka billh. Is there any evidence for it? If so, you should share it and if not, you shouldn't make such accusations. This may be true, but this troll doesn't fit the pattern with billh. Agreed. While billh seems to enjoy the show when a creative troll shows up, flooding is definately not his style. Besides, he's busy with a cool new project... Rik -- Bravely reimplemented by the knights who say NIH. http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Technical Differences of *BSD and Linux
[follow-ups to [EMAIL PROTECTED], please] On Fri, 24 Jan 2003, Josef El-Rayes wrote: as you can see your questions are not very welcome on the mailinglists, therefore i advice you to have a look at this book if you are interested in BSD's technical background There is one mailing list where this kind of discussion probably would be welcome, the kernelnewbies mailing list. Personally I'd really like more things related to BSD, Hurd and other freely available systems on the kernelnewbies mailing list, irc channel, etc. I might have founded #kernelnewbies to help people with Linux questions, but it was never my intention to limit it to Linux kernel stuff only. Title: The Design and Implementation of the 4.4BSD Operating System Authors: McKusick, Bostic, Karels and Quarterman Publisher: Addison-Wesley 4.4BSD is what NetBSD, OpenBSD and FreeBSD are basing on. For Linux i cant help you. I can recommend Understanding the Linux Kernel, 2nd edition. Other people have recommended various other kernel related books, you can find a small list on: http://kernelnewbies.org/books.php3 cheers, Rik -- Bravely reimplemented by the knights who say NIH. http://www.surriel.com/ http://guru.conectiva.com/ Current spamtrap: a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why did FreeBSD fail?
On Tue, 20 Aug 2002, Mosko Bilekic wrote: Gentlemen, it's time to explain why FreeBSD is such a failure. Maybe it's because the developers prefer to spend their time and energy on gossip instead of technical issues ? No wait, those aren't the developers, can't be. Please tell me those aren't really the developers... (now, can we end the trolling and talk techical stuff again? maybe I'll even join #bsdcode again ;)) cheers, Rik -- Bravely reimplemented by the knights who say NIH. http://www.surriel.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM: dynamic swap remapping (patch)
On Sat, 29 Sep 2001, Alfred Perlstein wrote: * Vladimir Dozen [EMAIL PROTECTED] [010929 14:38] wrote: P.S. Anyway, I do NOT insist my solution is better, and even that it is good for anything at all. It was fun for me to hack in BSD kernel, and it was interesting challenge, and I feel need to share results with others. At worst, I will recommend our customer to setup processing farm under FreeBSD with applied patch. I'm really impressed with the work you put into this, but it seems that you've tried to tackle two problems at the same time, Indeed, the whole idea of swapping tasks to the filesystem in nice, but having the task do this all by itself isn't a good option for many people... My suggestion, (but not my final say, i'm still open to ideas): Implement a memory status signal to notify processes of changes in the relative amount of system memory. When memory reaches a low or high watermark, the signal is broadcast to all running processes. The default disposition will be to ignore the signal. The signal will be named SIGMEMINFO. (SIGXfoo means 'process has exceeded resource foo') That'd be SIGDANGER, right ? b) do the following enhancement: Provide a system whereby you can swap to the filesystem without additional upcalls/syscalls from userspace, basically, provide some means of paging to the filesystem automatically. Sounds like a winner, when swap runs out a process gets suspended onto the filesystem automatically and SIGDANGER is sent out to give others a chance to clean themselves up. If enough space is freed, the suspended process can get back into the system. This should also preserve leaky applications while at the same time leaving the system intact... regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM: dynamic swap remapping (patch)
On Sat, 29 Sep 2001, Vladimir Dozen wrote: I have wrote a patch that modifies behaivour (have I spelled this word right? ;) of VM when we are out of memory. Instead of killing largest process, we remap parts of it's address space onto temporal files (exactly as HP-UX does when swapping into dir turned on). This is not instead of killing, this is just a way to delay the killing of processes longer. Once your disk is full you'd still run into the choice between a deadlock and a kill... It's an awesome way of delaying the out of memory problem, though, because a suspended application won't be able to allocate anything more, giving the system a better chance to let the running apps run to completion. Alternatively, the one leaky application is suspended and the rest of the system continues to run without any problems. In short, I like it ;) regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
On Sun, 19 Aug 2001, Matt Dillon wrote: : Uh, I don't think you understand what this limit is about. It's :essentially the limit on the amount of filesystem directory data that :can be cached. It does not limit the amount of file data that can :be cached - that is only limited by the amount of RAM in the machine. Yes, and the buffer cache determines how much dirty file-backed data (via write() or mmap()) the system is allowed to accumulate before it forces it out, which should probably be the greater concern here. How hard would it be to allow dirty data in the file cache, without buffer mappings ? regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recommendation for minor KVM adjustments for the release
On Sat, 18 Aug 2001, Leo Bicknell wrote: On Sat, Aug 18, 2001 at 06:34:43PM -0700, Peter Wemm wrote: No. I have a machine with 6GB in it waiting for finishing the PAE tweaks. Intel ppro, pentium2 and pentium3 has a maximum RAM of 64GB. Pentium4 may have more but I have not checked. It was my understanding from a previous thred that FreeBSD wasn't going to support this due to some problems it introduces, but I may be mistaken. Nah, most of that thread consisted of people telling me FreeBSD would never support it because they didn't think it was worth their time to implement. But we all know that all it takes is one skilful person who thinks it's worth implementing and writes the code to support PAE ;) regards, Rik -- IA64: a worthy successor to i860. http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Why page enable in Kernel space?
On Wed, 8 Aug 2001, craig wrote: I think the performance is the most important in kernel, other thing is second. I remember in linux linear address is real physical address in kernel space(is it true?). Why freebsd does not do in the same way? 1) wouldn't you think things like reliability to be more important than performance? ;) 2) Linux uses a 1:1 mapping of physical memory for the bulk of kernel memory, with physical address 0 mapped at virtual address 0xc000 and using 4MB pages 3) FreeBSD does do something remarkably similar, except that FreeBSD, IIRC, seems to put more of its data in 4 kB pages so the system has more flexibility wrt. where to allocate the kernel data ? regards, Rik -- IA64: a worthy successor to the i860. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Allocate a page at interrupt time
On Tue, 7 Aug 2001, Terry Lambert wrote: Matt Dillon wrote: All the cpu's don't get the interrupt, only one does. I think that you will end up taking an IPI (Inter Processor Interrupt) to shoot down the cache line during an invalidate cycle, when moving an interrupt processing thread from one CPU to another. You have a lot of fantasy today. You may want to consider reading one of the white papers you referred us to with so much enthusiasm and trying again later ;) Well, if you happen to have four NICs and four CPUs, and you are running them all full bore, I would say that wiring the NICs to the CPUs would be a good idea. That seems like a rather specialized situation, though. I don't think so. These days, interrupt overhead can come from many places, Exactly. You never know where your interrupts come from, so wiring them in a fixed setup really isn't going to do you much good in the generic case. Now if you want to optimise your source code for something like a Mindcraft benchmark ... regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, Julian Elischer wrote: On Thu, 2 Aug 2001, Rik van Riel wrote: On the really large machines, this can lead to the situation where even the page tables hardly fit into KVA. 4MB pages seem like the only solution ... There is no reason why we need to keep the kernel and the user process in the same 4GB map except for efficiency. There have been many UNIX machines in the past which put them in separate virtual spaces That was on machines where the CPU could actually address two separate spaces at once, right ? (like eg. m68k) The kernel would haev 4GB for itself and each process would have 4BG. System calls would be come more expensive as each would require a full page-table swap and a TLB flush. However it might be worth it for some people. Interrupt handling would also require a full page table swap and TLB flush. Considering that, I think the number of people for whom this will be worth it has probably dropped a bit ;) Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, mark tinguely wrote: The addressing use 64 bits for a memory pointer and the additional page indirection add to the overhead. The stickler is the MMU is still 32 bits. This means the PAE must segment the 64GB space into 4GB segments or 4 1GB segments. The OS must manage which pages are viewable to the process at this time. There's a better option. The application does this stuff itself, by mapping and unmapping SHM segments. This needs to be done anyway, since the application wouldn't be happy if the OS randomly remapped its address space to different pages ;)) There is a third mode of addressing using 2MB pages (simular to the 4MB page addressing mode for the 32 bit addressing scheme) that will only give a process access to 4GB of memory (not segmentable to a larger space, but can address physical memory located above the 4GB address). You can do that with 4kB pages too. Both the middle page directory and page table have 512 64-bit entries, so you can simply map 4kB pages from above the 4GB physical boundary... regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, Terry Lambert wrote: Rik van Riel wrote: Only if you want to use it all within one process. No. It still bites you if you want to do IPC, etc., since you can not guarantee the structures used for this are all within the non-segmented region of memory. Wrong. Your process can have pages from all over the 64 GB mapped into its page tables. Try doing this with code pages in one segment, the stack in another, and the data being referenced in a third. It will not work. Of course it cannot work. The segments you refer to will map to the linear 4GB space represented by the page tables. Those page tables can map, in their 4GB virtual space, pages from all over the 64GB physical space. I've seen a bunch of the machines. They're rather popular with the database folks. Name an OS that supports this; more than likely, you will have to appeal to a purpose built embedded system. Linux SCO Unix NT *cough* So it's not unreasonable to think of putting 8G or 16G in a box, and being able to map it all. You can never map it all, since your virtual address space is limited to 4GB... Overlays. A technology from the dawn of time, I know, but so are segment registers. s/You can never map it all/You can never map it all at once/ Happy now? ;) Basically the database folks are really keen on keeping their 3GB user addressable memory, so the kernel will remain limited to 1GB of KVA. They shouldn't care, since they are getting more memory. You're telling the people working with 50GB datasets that they shouldn't care about how many of their 512MB segments they can map in at once? ;) or just wait for IA64, rather than throwing developement effort into something that will end up in a scrap heap before it gets reasonable performance, or perhaps before it's even deployed. Ssssh, don't tell that to the folks who are using such machines today ;) cheers, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, Charles Randall wrote: From: Terry Lambert [mailto:[EMAIL PROTECTED]] I have yet to see one person using it for anything. So far, it is nothing more than marketing fodder: I haven't seen one motherboard capable of more than 4G worth of SIMMs. The Dell PowerEdge 6450 supports 8 GB of RAM. http://www.dell.com/us/en/biz/products/model_pedge_pedge_6400.htm It's all a trick, they don't really exist. After all, why would people ever shell out the money for one of these useless beasts that won't be running until ia64 has gotten cheaper than these machines ? Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, Terry Lambert wrote: Original poster said he was working on it for Linux, which means it's not done, which means not Linux. It's been running for a while now, integrated in the 2.4 kernel. The way Linux manages to avoid the horrors you describe is by simply not letting the kernel use more than its 1GB (or 2GB) of KVA. No special tricks to make the kernel use more memory, let it go on a diet instead. FWIW, on the Linux has it, so FreeBSD should have it arguments: If all your friends jumped off a cliff... Fully agreed, but as long as you don't do any weird tricks trying to let the kernel itself use more memory, it's not at all like jumping from a cliff ... Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, Terry Lambert wrote: Correct me if I'm wrong, and 64 bit PCI cards can in fact DMA at offsets above 4G, in the physical address space... They can. And for 32 bit PCI cards you simply use bounce buffers in the same way you handle ISA bounce buffers. It's ugly, but if you have a huge dataset it's better than getting the data from disk. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, Kenneth Wayne Culver wrote: Also, the PIII CAN'T natively support more than 4GB of ram. If a particular PIII motherboard supports this, then it's using some kind of wierd chipset that allows this to happen. 4GB is the limit with a 32 bit chip I believe; and the PIII is a 32-bit chip. The Xeon series have 32 bits of virtual address space and 36 bits of physical address space. Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Thu, 2 Aug 2001, Kenneth Wayne Culver wrote: Replying above an email because the curser is there is like shitting in your pants because your ass is there when you need to go to the toilet. BUT, don't the motherboards also have to support this? And isn't it only supported through some wierd segmentation thing? Yes, the mainboard needs to support the memory. No, there is no weird segmentation thing, at least not visible from software. regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Fri, 3 Aug 2001, Terry Lambert wrote: You still haven't told me what Linux does for 2x4G processes and a 1G kernel with only 8G of physical RAM. I rather suspect that as soon as your usage exceeds real memory, it all goes to hell very quickly, since your L1 and L2 caches are effectively disabled by the frequent reloading of CR3 and CR4 on context switches... Page tables can point to pages all over memory, there is no need to use stupid segment tricks for anything. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Wed, 1 Aug 2001, Terry Lambert wrote: craig wrote: I know PIII can support 64G physical memory. In FreeBSD how can I visit such range memory(4G-64G) ? The short answer is you can't. The longer answer is that you end up having to window it using segmentation; Only if you want to use it all within one process. You can have multiple 2 GB (that's the maximum process size in FreeBSD, right?) programs at the same time, happily using all physical memory. Only the FreeBSD memory management subsystem doesn't support it (yet?). This basically means that the memory is useless as a DMA target or source for disk controllers or gigabit ethernet cards, and is pretty useless for swap, ... So for limited uses in data intensive applications, it might be usable, And for those data intensive applications, it is very useful indeed... But to directly answer your question: by rewriting much of the low core virtual memory and page mapping handling code to know about segmentation. Not just that. There is a more insidious problem with the FreeBSD VM code and support of huge machines. The part of handling the PAE extended page table format and mapping high memory pages in and out of KVA (kernel virtual address) memory to copy stuff is easy. Problem is that you'll have to fit all of FreeBSD's VM data structures in the 2GB of KVA. This just isn't going to fit with the size the data structures have today ... So in order to support huge memory machines right, you'd have to put a number of FreeBSD's VM data structures on a rather strict diet. regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to visit physical memory above 4G?
On Wed, 1 Aug 2001, Mike Smith wrote: I know PIII can support 64G physical memory. In FreeBSD how can I visit such range memory(4G-64G) ? You can't. Those memory ranges are strictly off-limits to non-US citizens. And under the DMCA, US citizens aren't allowed to build or distribute PAE36 circumvention devices. Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MPP and new processor designs.
On Thu, 26 Jul 2001, Hugh LaMaster wrote: - Since the mid-70's (that is 25 years now), logic/gates/real-estate are no longer (economically) scarce - Therefore, the key to the value/efficiency of any computer architecture is how well it uses memory - There are two key components to memory hierarchy performance- latency and bandwidth Three basic truths, which spell an interesting future for Merce^WItanic ;) Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Network performance tuning.
On Thu, 12 Jul 2001, Matt Dillon wrote: yield an immediate improvement in available mbuf space. For the receive side of things we can't really do anything with existing connections (because we've already advertised that the space is available to the remote end), In emergencies it should be easy enough to just not ack the packets and drop them, this should cause the remote end to slow down and the connection to use less memory. Not the most elegant method, but probably usable DoS protection. cheers, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: deny this
On Mon, 9 Jul 2001, Mustafa N. Deeb wrote: how can I tell sendmail to deny this MAIL From: SIZE=1926 250 ... Sender ok Please see http://www.rfc-ignorant.org/ Denying these headers will get you blacklisted. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
On Tue, 26 Jun 2001, Wes Peters wrote: Rik van Riel wrote: On Sun, 24 Jun 2001, Rahul Siddharthan wrote: Wes Peters said on Jun 23, 2001 at 23:28:42: Plenty of GNU stuff there, though it doesn't say so explicitly. Of course, they say it's all meant only for legacy Unix stuff. Can you substantiate your claim there is plenty of GNU stuff in Interix, or are you just talking out your ass as usual? gcc, gdb, bash, gnu emacs and a bunch more. Out of several hundred utilities? [snip troll] /taunt weenies=Linux I hope you're having fun receiving flames from more impressionable people ;) Personally I don't care much about BSD vs. GPL and am annoyed by Microsoft's hypocricy (sp?). The fact that they're using open source software is great. cheers, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
On Sun, 24 Jun 2001, Rahul Siddharthan wrote: Wes Peters said on Jun 23, 2001 at 23:28:42: Plenty of GNU stuff there, though it doesn't say so explicitly. Of course, they say it's all meant only for legacy Unix stuff. Can you substantiate your claim there is plenty of GNU stuff in Interix, or are you just talking out your ass as usual? gcc, gdb, bash, gnu emacs and a bunch more. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max kernel memory
On Wed, 20 Jun 2001, Terry Lambert wrote: Back to swapping socket structures... You could swap them if you wanted to give up some KVA space to be able to do it. Which is a problem, especially for Linux. The problem here is that there are x86 machines around with 64GB of RAM. Linux has just under 1GB of KVA and FreeBSD has (IIRC) 2GB of KVA. Even the FreeBSD figure is just 3% of RAM on those machines. With the KVA being that low a percentage of the total amount of physical memory, you really have to watch carefully at all the excess fat on your data structures... This would certainly be true for the page table and pmap architecture in FreeBSD; Linux is already running into the problem that under some (common on such machines) workloads on the 16GB - 64GB sized machines the needed page tables are almost as large as the total KVA. The solution for this will probably be the use of 2MB pages for the large SHM segments and mmap()ed files. This way we can keep the flexibility of paging (needed by SAP) and bring the pagetable overhead down a factor of 512 ;) I personally do not think that that is worth it: Nothing but violent agreement here. The really fundamental problems with FreeBSD at this point devolve down to some moderately easily repaired historical artifacts in its VM architecture and allocation techniques and policies, as well as administrative limits for general purpose use being the defaults, with no way to autotune based on workload. Most of the fixes have been known in the literature since the early and mid 1990's (though some are more recent). These aren't even that fundamental. In Linux 2.2 and 2.4 we solved most of these autotune thingies without too much impact on the code. The only major problem is that the writers of each subsystem set a too high maximum for their subsystem ... something I'm slowly getting around to fixing ;) cheers, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Query: How to tell if Microsoft is using BSD TCP/IP code?
On 21 Jun 2001, Dag-Erling Smorgrav wrote: Andy [EMAIL PROTECTED] writes: http://linuxtoday.com/news_story.php3?ltsn=2001-06-20-018-20-NW-MS-SW Doesn't this mean software developed with Microsoft's SDK is viral? And doesn't *that* mean you're not allowed to develop it with Microsoft's SDK? And doesn't this sound a bit circular? http://msdn.microsoft.com/msdn-files/027/001/516/eula_mit.htm Particularly clause 1 (c). What was it again about a cat in a corner making weird jumps? ;) Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: max kernel memory
On Wed, 20 Jun 2001, Matt Dillon wrote: I don't think this represents the biggest problem you would face, though. It is far more likely that hung or slow connections (e.g. the originator goes away without disconnecting the socket or the originator is on a slow link) will represent the biggest potential problem. It's too bad we can't 'swap out' socket buffers! Even that wouldn't save you from running into address space issues with the kernel, unless you replace all pointers with other kinds of indices ... but that'll probably make things messy. regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article: Network performance by OS
On Sat, 16 Jun 2001, Matt Dillon wrote: This is old. The guys running the tests blew it in so many ways that you might as well have just rolled some dice. There's a slashdot article on it too, and quite a few of the reader comments on these bozos are correct. I especially like comment #41. Don't worry, FreeBSD stacks up just fine in real environments. The only thing that worries me a bit is that both FreeBSD and Linux needed to be tuned at all to run these things, even if it was just the maximum file descriptor setting. A lot of this tuning could easily be done dynamically (and is done dynamically on linux 2.4), but lots of it still has static maximums which have to be tuned by hand. Compile-time tuning for stuff which can be dynamically allocated (and freed) is IMHO a big sillyness in the OS. Yes, this report was completely useless as a benchmark, but it DID highlight a point where Linux and BSD can be improved: dynamic allocation (and freeing) of things like file descriptors and socket structures. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Article Network performance by OS
On Sat, 16 Jun 2001, Jonathan Fortin wrote: Linux is tuned out of the box, where the others are tuned for stability. Not quite. Linux distributions tend to be extremely conservative in the IDE options (DMA, interrupt unmasking, write caching, etc. all disabled) while FreeBSD seems to have write caching and DMA on by default... Both systems have tuning out of the box in different ways. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Sysadmin article
On Fri, 15 Jun 2001, Terry Lambert wrote: [ ... Eliza program for FreeBSD ... ] Doing this is non-trivial. Many of the things they should have tuned can not be tuned except at compile time. I think you just hit the nail on the head and managed to identify the problem... regards, Rik -- Executive summary of a recent Microsoft press release: we are concerned about the GNU General Public License (GPL) http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Real technical comparison
On Wed, 30 May 2001, Albert D. Cahalan wrote: I would suggest a better test would be to open _at least_ 250,000 connections to a server running under both FreeBSD and Linux. I was able to do this without breaking a sweat on a correctly configured FreeBSD 4.3 system. How about a real benchmark? Good question indeed. All proposed benchmarks in this thread have been geared heavily towards one system or the other and are not at all industry standard benchmarks. At www.spec.org I see SPECweb99 numbers for Solaris, AIX, Linux, Windows, Tru64, and HP-UX. FreeBSD must be hiding, because I don't see it. BSDI, Walnut Creek, and WindRiver all have failed to submit results. Linux is still #1 for 1 to 4 processors. The 8-way results need to be redone on newer hardware (Windows is ahead now) and Linux doesn't have 6-way or 12-way numbers. Last I heard the 8-way result with Windows had an NC (not qualified) next to it. OTOH, Linux' 8-way numbers still leave a lot to be desired ... Go on, show some numbers. Stop hiding. *nod* We can all brag about our performance being better than the others, but unless some actual numbers on a standardised benchmark are being published, it's nothing more than just bragging and bullshitting each other. If FreeBSD's performance is as good as people say (which I'm not doubting, at least as far as the realistic claims go), then where are those impressively high specweb numbers? ;) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Real technical comparison
On Thu, 31 May 2001, Noses wrote: Thank you for not telling it to one of my servers which is running around with about 10 concurrent connections biting its tail. I wouldn't like to hurt its feelings. And I've got the feeling that it will have to bear a bit more of that beating. Interesting, what's that thing doing ? Mmm, now that I think of it, at least one company wants to run a stateful firewall VPN endpoint with well over 128.000 connections too (and on Linux 2.4, even ... this would be an interesting thing to test). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Real technical comparison
On Thu, 31 May 2001, Søren Schmidt wrote: If somebody sends me the 800 US$ the software costs, or better get me the software for free (we are a free OS right) I'll gladly run it through a variety of machines here... If you think this is the problem, I'll happily chip in $50; it would be interesting to see some numbers... Note that I'll drop offline for a week or so now, I'll be unplugging my laptop in a minute to display my gf's lecture's slides and then I'll be off for holidays ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Real technical comparison
On Wed, 30 May 2001, Terry Lambert wrote: The intent of the test is obviously intended to show certain facts which we all know to be self-evident under strange load conditions which are patently unreal. I would suggest a better test would be to open _at least_ 250,000 connections to a server That would certainly qualify for the patently unreal part, but I don't know what else you want to prove here. This could easily be the case with, for example, a pager network or other content broadcasting system, or an EAI tool, such as IBM's MQ-Series. Doing a gigabit per second in 3kB per second connections doesn't seem all that realistic when you realise that they'll want their messages only acknowledged when they are safely on disk, etc... Think transactions. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
On Mon, 28 May 2001, Daniel C. Sobral wrote: Rik van Riel wrote: On Fri, 25 May 2001, Terry Lambert wrote: So add an option to sysinstall called: Fast and at least as reliable as Linux I doubt FreeBSD would need to enable write caching in order to be as fast as Linux (which doesn't have write caching enabled in any distribution I'm aware of). ;)) AFAIK, ata write caching is enabled by default by the hardware manufacturers. This was not the case originally, but benchmarks spoke louder. Hmmm, true. I've even heard that you cannot switch it off on some drives, or even stranger, drives that allow you to turn it off but automatically switch it on again under heavy load... As Andre Hedrick says storage is a lie. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
On Fri, 25 May 2001, Terry Lambert wrote: So add an option to sysinstall called: Fast and at least as reliable as Linux I doubt FreeBSD would need to enable write caching in order to be as fast as Linux (which doesn't have write caching enabled in any distribution I'm aware of). ;)) The hole VM / FS write clustering thing is an area where Linux still has to catch up with FreeBSD (at least in theory FreeBSD's subsystem here is much more advanced). If, for some reason, FreeBSD _does_ turn out to be much slower than Linux (which I doubt), chances are something is just tuned wrong. All code I've seen indicates that Linux should be lagging FreeBSD in this area... (and no, reiser doesn't really count since it's not all that reliable yet ... like Matt wrote, it has a long way to go until it reaches reliability) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Sat, 26 May 2001, Peter Wemm wrote: Which is more expensive? Maintaining an on-disk hashed (or b+tree) directory format for *everything* or maintaining a simple low-cost format on disk with in-memory hashing for fast lookups? I bet that for modest directory sizes the cost of disk IO outweighs the added CPU usage by so much that you may as well take the trouble of using the more scalable directory format. For the small directory case I suspect the FFS+namecache way is more cost effective. For the medium to large directory case (10,000 to 100,000 entries), I suspect the FFS+namecache method isn't too shabby, providing you are not starved for memory. For the insanely large cases - I dont want to think about :-). The ext2 fs, which uses roughly the same directory structure as UFS and has a name cache which isn't limited in size, seems to bog down at about 10,000 directory entries. Daniel Phillips is working on a hash extension to ext2; not a replacement of the directory format, but a way to tack a hashed index after the normal directory index. This way the filesystem is backward compatible, older kernels will just use the old directory format and will clear a flag when they write to the directory, this can later be used by the new kernel to rebuild the hashed directory index. It also has the advantage of being able to keep using the triedtested fsck utilities. Maybe this could be an idea to enhance UFS scalability for huge directories without endangering reliability ? regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Wed, 23 May 2001, Shannon wrote: On Wed, May 23, 2001 at 10:54:40PM -0300, Rik van Riel wrote: 1. I don't think I've ever seen a Linux distro which has write caching enabled by default. Hell, DMA33 isn't even enabled by default ;) You are talking about controlling the IDE drive cache. The issue here is write cache in the filesystem code. 1) IIRC they were talking about hw.ata.wc 2) soft-updates _is_ a form of write cache in the filesystem code, in fact, that's one of the points of soft-updates in the first place ;) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: technical comparison
On Wed, 23 May 2001, Andresen,Jason R. wrote: On Wed, 23 May 2001, Kris Kennaway wrote: That's all well and good, but I thought the aim here was to compare Linux and FreeBSD performance on as level playing field as possible? You're not measuring FS performance, you're measuring FS performance plus cache performance, so your numbers so far tell you nothing concrete. *nod* Yes, they tell us that FreeBSD with softupdates and no write cache performs better in large cases than Linux with ext2fs and write caching enabled. Also my FreeBSD 4.0 boxes don't have the hw.ata.wc knob, so it's harder for me to test this. Also, I don't know how ones goes about disabling the write cache in Linux without recompiling the kernel (which we have some custom mods in place, so I'm reluctant to do this). 1. I don't think I've ever seen a Linux distro which has write caching enabled by default. Hell, DMA33 isn't even enabled by default ;) 2. hdparm -W0 /dev/drive to turn write caching off, -W1 to turn it on 3. I've seen many disks which got _slower_ with write caching turned on. Sure, it helps for sequential IO, but with more random IO the write caching on the disk can interfere really badly with the IO scheduling in the OS ... I've seen as much as a 5x drop in random IO performance with write caching ON compared to OFF. I guess it would be good to follow Kris' suggestions and try to do the tests on a level playing field. The results might just be interesting ;) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
SMP in 2.4 (fwd)
Hi, better back out SMPng real fast, otherwise you'll get into a flamewar with Dennis again ;) Rik -- Forwarded message -- Date: Wed, 18 Apr 2001 11:08:22 -0400 From: Dennis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: SMP in 2.4 Does 2.4 have something similar to spl levels or does it still require the ridiculous MS-DOSish spin-locks to protect every bit of code? DB - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SMP in 2.4 (fwd)
On Wed, 18 Apr 2001, Dennis wrote: You think Intel isn't going to market dual/quad ia64 machines? Yes, but who'll need them? If nobody needed them, what would be the point in SELLING them ? I know you don't trust our technical instinct, but you might at least consider the business instinct of companies like Intel, IBM or Unisys (who all sell big SMP systems). Besides, there are LOTS of people who need tomorrow's performance yesterday. There will always be a big market for overpowered, overpriced SMP systems... And as for the "but you can wait 2 years until UP is faster than today's SMP" doesn't quite work for eg. investment banking and stock funds. More computing power means better calculations, which means more money. And for folks like them, computing power is not measured in FLOPS, but in ACRES. And when you're talking 3 acres of computing power, you'd better have some decend density (ie. SMP in 2U rackmounted boxes, or something similarly suitable). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Tue, 10 Apr 2001, Matt Dillon wrote: It's randomness that will kill performance. You know the old saying about caches: They only work if you get cache hits, otherwise they only slow things down. I wonder ... how does FreeBSD handle negative directory entries? That is, /bin/sh looks through the PATH to search for some executable (eg grep) and doesn't find it in the first 3 directories. The next time the script is started (it might be ran for every file in a large compile) the next invocation of the script looks for the file in 3 directories where it isn't present .. again. Does the vfs cache handle this or does FreeBSD have to go down into the filesystem code every time? Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Thu, 12 Apr 2001, Matt Dillon wrote: Again, keep in mind that the namei cache is strictly throw-away, This seems to be the main difference between Linux and FreeBSD. In Linux, open files directly refer to an entry in the dentry (and inode) cache, so we really need to have dynamically growing and shrinking caches in order to accomodate programs that have huge amounts of files open (but we want to free the memory again later, because the system load changes). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Tue, 10 Apr 2001, Matt Dillon wrote: :I heard NetBSD has implemented a FreeBSD like VM, it also implemented :a VM balance in recent verion of NetBSD. some parameters like TEXT, :DATA and anonymous memory space can be tuned. is there anyone doing :such work on FreeBSD or has FreeBSD already implemented it? FreeBSD implements a very sophisticated VM balancing algorithm. Nobody's complaining about it so I don't think we need to really change it. Most of the other UNIXes, including Linux, are actually playing catch-up to FreeBSD's VM design. In the balancing part, definately. FreeBSD seems to be the only system that has the balancing right. I'm planning on integrating some of the balancing tactics into Linux for the 2.5 kernel, but I'm not sure how to integrate the inode and dentry cache into the balancing scheme ... I'm curious about the other things though ... FreeBSD still seems to have the early 90's abstraction layer from Mach and the vnode cache doesn't seem to grow and shrink dynamically (which can be a big win for systems with lots of metadata activity). So while it's true that FreeBSD's VM balancing seems to be the best one out there, I'm not quite sure about the rest of the VM... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Tue, 10 Apr 2001, Matt Dillon wrote: :I'm curious about the other things though ... FreeBSD still seems :to have the early 90's abstraction layer from Mach and the vnode :cache doesn't seem to grow and shrink dynamically (which can be a :big win for systems with lots of metadata activity). Well, the approach we take is that of a two-layered cache. The vnode, dentry (namei for FreeBSD), and inode caches in FreeBSD are essentially throw-away caches of data represented in an internal form. The VM PAGE cache 'backs' these caches loosely by caching the physical on-disk representation of inodes, and directory entries (see note 1 at bottom). This means that even though we limit the number of the namei and inode structures we keep around in the kernel, the data required to reconstitute those structures is 'likely' to still be in the VM PAGE cache, allowing us to pretty much throw away those structures on a whim. The only cost is that we have to go through a filesystem op (possibly not requiring I/O) to reconstitute the internal structure. Which is ok if there isn't too much activity with these data structures, but I'm not sure if it works when you have a lot of metadata activity (though I'm not sure in what kind of workload you'd see this). Also, if you have a lot of metadata activity, you'll essentially double the memory requirements, since you'll have the stuff cached in both the internal structures and in the VM PAGE cache. I'm not sure how much of a hit this would be, though, if the internal structures are limited to a small enough size... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
On Tue, 3 Apr 2001, Dennis wrote: This "consumer" attitude that you are doing a company a favor by buying something from them is completely misguided. Most companies are not some ISP or consultant struggling to pay its bills. WE are doing you a favor by making our technology available to you at a fair price. Yeah yeah, companies are there for the stockholders. Screw the customers. While this is a nice short-term business plan, I'm really curious how this social experiment will end up in the long run. Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
On Thu, 22 Mar 2001, thinker wrote:
On Wed, Mar 21, 2001 at 04:14:32PM -0300, Rik van Riel wrote:
The (maybe too lightweight) structure I have in my patch
looks like this:
struct pte_chain {
struct pte_chain * next;
pte_t * ptep;
};
Each pte_chain hangs off a page of physical memory and the
ptep is a pointer to a page table entry.
The page struct of the page table page itself is used to
note down which address space and offset we have. This means
that FreeBSD's pv_pmap, pv_va and pv_ptem are in the page
table page and NOT in each pte_chain structure...
How about portability? It maybe efficient, but it is not easy
to port to other platforms.
IIRC the pmap layer is in the architecture-dependent code in
the BSDs. For Linux we have forward pagetables in every
architecture, whether it be in software or hardware. They
turn out to be quite adequate as an alternative to vnodes ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: tuning a VERY heavily (30.0) loaded s cerver
On Wed, 21 Mar 2001, Matt Dillon wrote:
We've looked at those structures quite a bit. DG and I talked about
it a year or two ago but we came to the conclusion that the extra
linkages in our pv_entry gave us significant performance benefits
during rundowns. Since then Tor has done a lot of cleanup, but
I don't think the analysis has changed much.
typedef struct pv_entry {
pmap_t pv_pmap;/* pmap where mapping lies */
vm_offset_t pv_va; /* virtual address for mapping */
TAILQ_ENTRY(pv_entry) pv_list;
TAILQ_ENTRY(pv_entry) pv_plist;
vm_page_t pv_ptem;/* VM page for pte */
} *pv_entry_t;
The (maybe too lightweight) structure I have in my patch
looks like this:
struct pte_chain {
struct pte_chain * next;
pte_t * ptep;
};
Each pte_chain hangs off a page of physical memory and the
ptep is a pointer to a page table entry.
The page struct of the page table page itself is used to
note down which address space and offset we have. This means
that FreeBSD's pv_pmap, pv_va and pv_ptem are in the page
table page and NOT in each pte_chain structure...
The only issue is address space rundowns, but this _could_
be ok due to the fact that systems usually seem to have more
short-running processes than long-running ones and the tasks
that are short-running will have their pte_chain nearer to
the beginning of the list.
Finding all pages in an address_space is simply done by walking
the populated parts of the page tables, this is cache friendly
and relatively fast for everything except really huge sparse
mappings (but in that case, the finer grained locking makes sure
this penalty gets restricted to the exiting task only and doesn't
block the rest of the system).
The whole patch is available at:
http://www.surriel.com/patches/2.4/2.4.1-pmap-swapsonuml
I have some newer code available, but haven't bothered coding
up a new patch yet since the reverse mapping is experimental
stuff and we're still busy finetuning and debugging 2.4 ;)
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gcc optimization problems (RE: optimizing apache with php andnfs mounts)
On Tue, 13 Mar 2001, Charles Randall wrote: From: David O'Brien [mailto:[EMAIL PROTECTED]] 2. The base, system C compiler is known to produce bad code with -O2. We have been proclaiming this since as long as I have been with the Project. Is this an issue with FreeBSD's gcc's or gcc in general? If gcc in general, are there open PRs on this issue? It's a gcc thing. Linux is having the same problems every once in a while (currently there only seem to be _2_ gcc versions which generate correct code for the Linux kernel ...). OTOH, it is possible to work around gcc problems in the code and code which was initially written for older gcc versions often rely on things which were true in older gcc versions but are no longer true currently ... (especially things depending on certain ordering of instructions and the (non-)presence of memory barriers) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD pthreads
On Sun, 4 Mar 2001, Jordan DeLong wrote: On Sun, Mar 04, 2001 at 11:08:51AM +, Jordan DeLong wrote: clone() wont count against the per uid process limit, right? actually I just realized it'd be incredibly stupid for clone not to count against the per uid process limit It does the exact same check a normal fork() would do, in fact it shares the same code path ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
On Sat, 24 Feb 2001, Peter Seebach wrote: In message 9820.983050024@critter, Poul-Henning Kamp writes: I think there is a language thing you don't understand here. No, I just disagree. It is useful for the OS to provide a hook for memory which is *known to work* - and that is the environment C specifies. Send patches. Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
On Sun, 25 Feb 2001, Matt Dillon wrote: The problem is a whole lot more complex then you think. Dealing with overcommit is not simply counting mapped pages, there are all sorts of issues involved. But the biggest gotcha is that putting in overcommit protection will not actually save your system from dying a terrible death. It in fact makes it *more* likely that the system will die a horrible death, Indeed, but since a lot of the non-overcommit fans will not believe this, why not let them find out by themselves when they write a patch for it? And maybe, just maybe, they'll succeed in getting their idea of non-overcommit working with a patch which doesn't change dozens of places in the kernel and doesn't add any measurable overhead. (a while ago we had our yearly discussion on linux-kernel about this, after some time somebody showed up with code to do overcommit ... and, of course, the conclusion that it wouldn't work since he got to understand the problem better while writing the code ;)) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
On Tue, 27 Feb 2001, Daniel C. Sobral wrote: Matt Dillon wrote: :Matt Dillon wrote: : :.. : the system runs out of memory, even *with* overcommit protection. : In fact, all sorts of side effects occur even when the system :... : :That's an assumption. Ha. Right. Go through any piece of significant code and just see how much goes flying out the window because the code wants to simply assume things work. Then try coding conditionals all the way through to fix it... and don't forget you need to propogate the error condition back up the procedure chain too so the original caller knows why it failed. sarcasmPerhaps you should re-acquaint yourself with exception handlers, And just where are you going to grow the cache when the exception handler runs off the edge of the current stack page ? Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting memory allocators for library functions.
On Mon, 26 Feb 2001, Peter Seebach wrote: In message [EMAIL PROTECTED], And maybe, just maybe, they'll succeed in getting their idea of non-overcommit working with a patch which doesn't change dozens of places in the kernel and doesn't add any measurable overhead. If it adds overhead, fine, make it a kernel option. :) Anyway, no, I'm not going to contribute code right now. If I get time to do this at all, I'll probably do it to UVM first. My main objection was to the claim that the C standard allows random segfaults. It doesn't. And yes, bad hardware is a conformance violation. :) I don't think a failed kernel-level allocation after overcommit should generate a segfault. IMHO it should send a bus error (or a sigkill if the process doesn't exit after the SIGBUS). Rationale: SIGSEGV for _user_ mistakes (process accesses wrong stuff) SIGBUS for _system_ errors (ECC error, kernel messes up, ...) cheers, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO problems
On Mon, 5 Feb 2001, Matt Dillon wrote: :file: table is full :looutput: mbuf allocation failed :nfs server 172.16.0.101:/bravenet1/home: is alive again This sheds a considerable amount of light on the problems... methinks you may have a low 'maxusers' setting in the kernel config. Read on. Linux had problems with errors like this too, with kernel 2.0 and 2.2 when used under heavy load. In kernel 2.4 this has been solved by simply having the kernel allocate (and free) these structures on demand ... would that be an idea for FreeBSD ? Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Charles Randall writes: The qmail FAQ specifically recommends against soft updates for the mail queue. http://cr.yp.to/qmail/faq/reliability.html#filesystems Is this incorrect? It seems to indicate that qmail doesn't use fsync(2) as much as it should do. If that is true, then yes, softupdates would mean that a lot of things which qmail (mistakenly) think has been written are in fact not on the disk. If this is true, I guess qmail can be officially considered broken. IIRC SMTP requires you to wait until the data is on stable (non-volatile) storage until you are allowed to return SMTP 250... The system call used to guarantee this is fsync (and friends?); if qmail doesn't use it but makes assumptions that aren't true on any decent OS out there ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Mike Silbersack wrote: On Tue, 6 Feb 2001, Rik van Riel wrote: The system call used to guarantee this is fsync (and friends?); if qmail doesn't use it but makes assumptions that aren't true on any decent OS out there ... Well, the various qmail programs do seem to fsync (though I'm not sure if it's in the right places.) ftp://elektroni.ee.tut.fi/pub/qmail_linux_metadata_message : So what is this all about? qmail relies on the BSD semantics of ^^^ immediate update of directories on the disk when link(), unlink(), open() and rename() calls are used. Pre-softupdate BSD semantics, apparently. Doesn't sound like the smartest thing to do when you want a reliable MTA... But Linux writes them to the disk asynchronously. My library loaded before libc changes those calls to do the corresponding directory writes too. Then qmail should be reliable against power outages also in Linux. If djb could be considered to take things like reliability and the SMTP specification into account, and not just security, then qmail would have the potential to be a pretty decent mailer. As it is, I can only recommend people to go with something like postfix, Exim or zmailer ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Matt Dillon wrote: QMail's FAQ is totally incorrect. No major filesystem -- be it FFS, EX2FS, Reiser, FFS+Softupdates, guarentees that when you write() and close() a file that the file will then survive a disk crash. All these filesystems guarentee is that if a crash occurs, when the system reboots the filesystems will be recovered into a consistent state. Softupdates is considerably better at guarenteeing this consistency (as is something like Reiser), but if you crash a softupdates disk may wind up unwinding 'more' of the last few moments worth of operations then a normal filesystem would. And, I might add, Reiser is the same way. Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync() will not return until there is a commit point in the log. This means that fsync() will guarantee that the transactions won't be unwound (unless I've overlooked some weird special case situations where it is needed after all...). The only filesystems I can see being completely resilient against these destructive roll-backs would be LFS and tux2. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Matt Dillon wrote: :Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync() :will not return until there is a commit point in the log. : :This means that fsync() will guarantee that the transactions :won't be unwound (unless I've overlooked some weird special :case situations where it is needed after all...). Yes, I believe you are correct. I was operating under the impression that ReiserFS had only one log, though. I have not researched EXT3 so I can't comment on it. So if you fsync() a file under Reiser, aren't you fsync()ing the entire filesystem? It would only need to do 2 things: 1. put a sync point in the journal, after writing all the needed data to the journal (cheap, no disk seeks involved) 2. write out the file data to the filesystem For ext3, you can either go the same way as reiserfs or you can do full data journalling. With full data journalling you will end up writing the data twice, but you can return from fsync() after having synced the data to the journal only... This decrease in latency means that for some workloads doing full data journalling could give better performance than metadata-only journalling. And then, of course, there's the option of moving the journal to a separate device. In this situation doing data journalling will almost certainly improve performance if your workload has lots of fsyncs sincy you both cut down on the seek times needed for an fsync and the "real filesystem" has more freedom to reorder the writes it does ... the data has everything needed for the last few seconds, so why worry. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Andre Oppermann wrote: Date: Tue, 06 Feb 2001 20:32:07 +0100 From: Andre Oppermann [EMAIL PROTECTED] NAME link - make a hard file link DESCRIPTION The link() function call atomically creates the specified directory entry ^^ (hard link) name2 with the attributes of the underlying object pointed at by name1. If the link is successful: the link count of the underlying ob- ject is incremented; name1 and name2 share equal access and rights to the underlying object. IE. link() atomically creates the directory entry and increments the usage count of the inode. I don't see anything about writing the thing to disk ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Andre Oppermann wrote: Qmail depends on ordered-metadata updates (Terry! :-). That means if you issue a link() to the new place and a unlink() in the old place it should guarantee that the link() happens *BEFORE* the unlink(). As it is, I can only recommend people to go with something like postfix, Exim or zmailer ... Have a look at the qmail source and the facts before you spill out such a *bullshit*! If qmail depends on a behaviour which isn't guaranteed by some OSes ... Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Andre Oppermann wrote: Rik van Riel wrote: On Tue, 6 Feb 2001, Matt Dillon wrote: Reiserfs and ext3 have write-ahead logs and, AFAIK, fsync() will not return until there is a commit point in the log. Also FFS/UFS will not return before the file and directory entry is written to the disk. Not relevant for the point Matt was making... This means that fsync() will guarantee that the transactions won't be unwound (unless I've overlooked some weird special case situations where it is needed after all...). The only filesystems I can see being completely resilient against these destructive roll-backs would be LFS and tux2. This doesnt matter. If your machine crashes while receiving a message you're never going to issue a SMTP 250 to the sending mail server and it will try again later. We don't care if this incomplete queue file survives or gets purged. If you have a busy mailspool, it might just be the case that the OS is making another write to the same directory after your SMTP 250 has been issued. If the machine crashes during this write and leaves the directory in a state which cannot be recovered by fsck, the whole directory will be purged and you'll lose your messages. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Andre Oppermann wrote: But please answer me one question: Is the link() call atomically in FFS/UFS w or w/o softupdates? Meaning when the call returns the meta- data is written to stable storage like with fsync()? Since when does `atomic' equal `synchronous' ? regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
On Tue, 6 Feb 2001, Andre Oppermann wrote: Rik van Riel wrote: On Tue, 6 Feb 2001, Andre Oppermann wrote: But please answer me one question: Is the link() call atomically in FFS/UFS w or w/o softupdates? Meaning when the call returns the meta- data is written to stable storage like with fsync()? Since when does `atomic' equal `synchronous' ? Because otherwise it would not be atomically, would it? Could you explain to me _why_ you think this is the case ? AFAIK the atomicity means that link() creates the new directory entry and increases the inode usage count atomically, so the programs running on the system never get to see an inconsistent state (and to prevent against an unlink() running while the link() is "in progress"). regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch oflicence Jihad crap
On Sun, 7 Jan 2001, Jeremiah Gowdy wrote: You're saying the most common definition of "free" isn't no cost ? I'm a free man, not a commercial sample! Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch oflicence Jihad crap
On Wed, 27 Dec 2000, Jeremiah Gowdy wrote: If you slant your judgement so far against the other products, it makes you sound like you don't know what you're talking about (no offense). You need to point out the pros and cons of ALL three systems. Not just the pros of FreeBSD and the cons of Linux/Windows. Indeed. Not doing this makes the FreeBSD crowd look like a bunch of kids who shouldn't be taken seriously. Not only does this weaken FreeBSD (hey, not my problem), but it also weakens the opinion people have of the free unix systems in general ... which DOES create a problem for me (Linux is my fulltime job). regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: FreeBSD vs Linux, Solaris, and NT
On Tue, 19 Dec 2000, Matt Dillon wrote: Yes, it's a pretty sad state of affairs. What annoys me the most is that companies actually believe they are protecting something when they don't make their device driver source or hardware documentation available. It has been well proven for years that the most withholding accomplishes for the vast majority of these device drivers is a slight delay--- perhaps a week or two, before competitors figure out what they've done. And the big losers are, as always, the people who buy hardware with binary-only drivers. It's quite common for a manufacturer to completely stop driver development once a particular model of hardware (say a certain video card) is no longer sold. This, in turn, leads to the situation where the user has to chose between the following options: 1. don't upgrade the software, because a driver is not available for the new system 2. upgrade the hardware to a version which has a driver available for the new software If you go back to the introduction of eg. Windows 95, or Windows 2K, you will recognise this situation. Luckily the users of FreeBSD, Linux and the other free Unices have another option: 3. only buy hardware which has drivers available in source code ... these drivers can be easily ported to newer versions of the operating system and support for the hardware is ensured in the future THIS is the real reason for preferring source code support drivers. Not even the usually higher quality of the open source drivers or the faster availability of the manufacturer's drivers change this situation. regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: iowait CPU state
On Thu, 16 Nov 2000, Terry Lambert wrote: Modern bloat-ware really pisses me off; I built the bind library the other day: the frigging thing was 4M, unstripped. How does this affect the (non?-)usefullness of the %iowait statistic? When you are waiting for I/O in a well written program, it is because there's nothing left to do but wait, which would make the statistic useless. If there's something else you could do, and you're waiting, by definition the program is not well written (well written programs don't waste time for no good reason). Ummm, how about a situation where you have a steadily increasing work load (more customers?) and want to have decent statistics of your servers to determine exactly what parts to upgrade and/or if you need to put extra machines into service? I agree that *any* statistics become useless after some time in a completely static situation, but thruth is that the number of internet users is still increasing and the workload on servers is doing the same ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: iowait CPU state
On Thu, 16 Nov 2000, Terry Lambert wrote: Ummm, how about a situation where you have a steadily increasing work load (more customers?) and want to have decent statistics of your servers to determine exactly what parts to upgrade and/or if you need to put extra machines into service? Two words: capacity planning. For which you really want all the useful statistics the OS could give you. (including maybe the %iowait one) cheers, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: iowait CPU state
On Wed, 15 Nov 2000, Terry Lambert wrote: Thank you! This gets the me disk %busy, which is one of the things I was looking for. Now, can anyone tell me how to tell what percentage of processor time is being spent waiting for disk I/O to complete? Uh, none? If there is disk I/O pending, the processor just runs a different process... am I missing your question? I guess it might be useful to see the difference between "true" idle time and time the system couldn't do anything useful because it was blocked on the disk (but /should/ have done something useful...). You mean because the programmer didn't interleave their I/O, and wrote to a threads interface, or some other interface that's prone to subsystem stalling, instead? Interleaving IO only makes sense when you have tons of parallelisable jobs. If you have one big serial job this doesn't buy you anything... Yes, you can use a separate thread to queue IO in advance, but in this case it might just be useful to have the %iowait statistic so you know how much work to queue in advance. Then again, this may be a bad example. I can't quite put my finger on it, but somehow I have the idea that the %iowait may be a useful statistic to keep... Modern bloat-ware really pisses me off; I built the bind library the other day: the frigging thing was 4M, unstripped. How does this affect the (non?-)usefullness of the %iowait statistic? regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: iowait CPU state
On Fri, 10 Nov 2000, Terry Lambert wrote: Thank you! This gets the me disk %busy, which is one of the things I was looking for. Now, can anyone tell me how to tell what percentage of processor time is being spent waiting for disk I/O to complete? Uh, none? If there is disk I/O pending, the processor just runs a different process... am I missing your question? I guess it might be useful to see the difference between "true" idle time and time the system couldn't do anything useful because it was blocked on the disk (but /should/ have done something useful...). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is this how to use Freebsd?
On Thu, 2 Nov 2000, Don Muller wrote: Well, the company did not explain how, or why it happened. The programmer I work with suggested BSD.Of course I wanted security! Well, they gave me some explanation that the server was hacked at the xfs port. But later I was told that the ftp port on redhat 6.2 was the vulnerability, so they actually were not sure? So this is when we had the network people install Freebsd. And where my questions lie. I wouldn't trust *THOSE* people with any OS :) Linux and BSD are comperable in security; both rely on a competent admin to keep the system secure over time. Lacking a competent admin on-site, you may look into a free Unix which has the capability of semi-automatically upgrading itself. I suspect the BSDs can do that; Conectiva Linux, Debian Linux and all Debian derivatives do that too (apt-get). Systems lacking that ability will always be in danger of getting behind in security updates when the admins don't look after the machine... regards, Rik -- The Internet is not a network of computers. It is a network of people. That is its real strength. http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting Linux NIS to work with FreeBSD NIS servers
On Sun, 15 Oct 2000, Stephen Hocking wrote: The Linux box appears toknow about the users, it just cant get the passwords right - something tickles my mind about DES vs MD5, is this the case, and how do I convert my MD5 passwords if needed? Not needed. Configure both machines to use the same crypt for the passwords. (for linux it should be nothing more than editing the right file in /etc/pam.d/ and regenerating the passwords for all "local" users) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing to disk
On Fri, 29 Sep 2000, Doug White wrote: On Thu, 28 Sep 2000, Marc Tardif wrote: What is the quickest way of writing large amounts of data to disk? Sequentially. Disks run an order of magnitude faster if they have sequential data. Don't get too fancy with the ordering since the disk driver will just reorder it for you. Also, lots of disks no longer seem to write individual sectors, but instead read/write whole tracks at a time. (and then the whole sector thing becomes moot) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
