Re: Snowhite and the Seven Dwarfs - The REAL story!
On Tue, 30 Jan 2001, Mike Silbersack wrote: On Wed, 31 Jan 2001, Dan Langille wrote: On 30 Jan 2001, at 3:19, Giorgos Keramidas wrote: of filtering is necessary though. Unless, somebody thinks that this is "censorship", and a new flame about humans rights spawns out of nowhere. We're not stopping anyone from saying anything. We're just stopping them from saying it on our lists. -- Dan Langille Uh oh, I sense an argument over whether object files are expressive speech or functional tools coming on. :) Definitely expressive speech. Which makes GCC a creative, intelligent creature, doesn't it? ;) Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Snowhite and the Seven Dwarfs - The REAL story!
On Mon, 29 Jan 2001 00:23:48 -0800 (PST), Hahaha [EMAIL PROTECTED] wrote: Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and polite with Snowhite. When they go out work at mornign, they promissed a *huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven Dwarfs enter... That must be the most amusing Windows virus I've ever seen (it is a virus, isn't it?). Four spelling mistakes and five grammar problems in four lines of text, probably sent to millions of people. A few months ago someone suggested that all binary attachments should be stripped from freebsd-hackers mail. I believe it is still a very good idea, and patches tend to be posted as text anyway. Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Silent FreeBSD
On Wed, 27 Dec 2000, "Renaud Waldura" [EMAIL PROTECTED] wrote: I've got that FreeBSD gateway in a corner at my house, it works fine dandy but the constant noise (whirring fans, hard drives) gets on my nerves. What solutions have people explored to quiet down a computer system? (actual experience will be preferred over wild speculations). I'm already aware of PicoBSD, but I need more storage than just a floppy. Has anybody experimented with RAM cards? How about noise-proof enclosures? I knew a guy once who was doing sound work on an SGI box, and was constantly complaining about the noise. He finally decided to eliminate everying that moved in the box. The temperature in the case was so high he couldn't touch some parts without getting burnt (don't remember the exact figures.) After some smoke tests to establish the exact air flow, he ended up building a huge wooden container with all walls insulated with a thick layer of foam and a 2 meter chimney to exhume the hot air. It worked like charm, although I think he had to put one fan somewhere. The box was perfectly silent, and ran at a comfortable 30 degrees C, but it took him a few months to get it working, and he was a constant source of amusement to half the Uni population for a year. Trust me, you don't want to attempt a noise-proof enclosure (short of an air-conditioned machine room.) I suggest the following course of action: 1. get a quieter power supply 2. get a quieter fans 3. get a good new drives: they're quiet. 4. get used to the noise. I have three computers running 24/7 in my bedroom, and after some swapping of power supplies, the noise is perfectly bearable. Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, 17 Dec 2000, Tony Finch [EMAIL PROTECTED] wrote: Patryk Zadarnowski [EMAIL PROTECTED] wrote: Now that I think of it, there aren't many commercial microkernel systems out there with the possible exception of QNX and lots of little embedded toys. Mac OS X is based on Mach. Oh, that's right, that new kid on the block ;) I keep forgetting about Apple's talent for shooting itself in a foot ;) BTW, for the original poster: in case you don't know, there exists a port of 4.4BSD that runs on top of Mach (Lites.) Pat. PS. Before this starts a flame war, let me say that I really believe that MacOS X is a very good thing for everyone involved, although the choice of Mach for the microkernel seems a little arbitrary if not misguided. Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Fri, 15 Dec 2000, "SteveB" [EMAIL PROTECTED] wrote: SteveB Sorry for such a basic question, but I have been looking and can't SteveB find the answer. Is FreeBSD as microkernel or monolithic kernel like SteveB Linux? Can someone point me to the answer/ It's a monolithic kernel, like Linux and all other mainstream UNIX flavours except for OSF1 (ie. Digital UNIX or True64), which is based on a hacked-up version of the MACH microkernel. Even then, most microkernel researchers won't consider OSF1 a microkernel, as Digital (now Compaq) worked around the MACH problem (which is an i-cache hog) by moving much functionality back into the kernel. Now that I think of it, there aren't many commercial microkernel systems out there with the possible exception of QNX and lots of little embedded toys. NT, sometimes claimed to be a microkernel, is far from it. Rather, it's simply another reasonably-well structured kernel. With 300+ system calls in the nucleus, the NT kernel handles just about everything except for major GUI tasks. Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ANSI C Standard and wchar*
On Mon, 31 Jul 2000, "Michael C. Wu" [EMAIL PROTECTED] wrote: Michael Hi all, Michael I am working on completing a BSDL'ed implementation Michael of wchar* that is *not* broken. However, Michael I could not find a free copy of ANSI C library standard. Michael I was wondering if anyone has an electronic copy of Michael ANSI/ISO/IEC 9899-1999 Programming Languages - C Michael and the related POSIX documents. (Yes, the document Michael only costs $18 on ANSI.org, but I really do not want Michael to purchase something that I probably will not use again.) Michael Also, which part of POSIX governs the correct Michael behavior for wchar*? POSIX.1? Michael Finally, I know that someone has been working on the Michael same thing. Would the person in question or someone please send Michael me what they have. Michael I apologize for the confusion. Many thanks. Michael, These standards are copyrighted, and ANSI.org is very clear about the electronic copies being for personal use only, not to be shared. Considering that, previously, you could not buy ISO C for less than $300, having a standards organization that sees the light is a good thing, and, I suggest that we all respect that. That is, you will not (should not) find anyone who'll offer to share electronic copies of the standard. I believe that the answer to your POSIX question is "none". I don't think POSIX deals with the wchar_t issue at all (someone correct me if I'm wrong.) Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is traditional unixes kernel really stable ?
"Yevmenkin, Maksim N, CSCIO" wrote: only one :-) performance :-) context switch is a slow operation. Thanks, emax Excuse me gentleman, who said that ? Take time to visit this site: http://www.qnx.com/iat/download/index.html You'll be introduced to a hard-real time OS (with a very modular design). The while OS fits in a single floppy with TCP/IP, GUI, web browser, http server, and again, all that in a single floppy. HOw can it be done? This OS uses microkernel arch. Fill their form in order to get a book describing its OS internal arch. Can some here explain me why such approach is not taken by FreeBSD? Yes. FreeBSD is based on the BSD monolithic kernel. It's precisely the ``other camp'' to the u-kernel guys (like myself.) Hence the ``BSD'' in its name. ;) Pat. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
On Wed, 5 Apr 2000, G. Adam Stanislav wrote: Lack of extensibility and variants. Don't they just love the great extensibility means aka non-standardized and non-standardizable "private use area" that defeats the whole idea of having a standard charset? Absurd! The private use area is for application specific usage. Suppose you want to design a database of cleaning supplies. You create a font for the use with your application, which will draw soap, mop, towel, and things like that. These are not in Unicode, and your odds of convincing the Consortium to include them are slim. So, your application will assign points within the private use are to soap, mop, towel, etc. This is what it was intended for, however this is not how it is used. I understand why Unicode Consortium is unlikely to include Klingon alphabet into "blessed" by them charset, however the use of private area for Klingon is hardly application-specific. When instead of fictional (even though relatively well-known) charset the question is about the representation of "obscure" or even hypothetic details of some real-world charset, things become much more hairy. Labeling of charsets and languages in multiple-charsets environment (even if in the case of Klingon the "charset" is Unicode with something added in the private area) can eliminate ambigiuty without involving ISO, Unicode consortium, etc. and without destabilizing "standards" by constant changes. Can it? People have been begging ISO to standarise 8 bit charsets for ages. If you tried to exchange information in polish in the pre-8859 days, you'd know why (about five radically different charsets in common use) Besides, if the alphabet for information interchange doesn't deserve standarising, I don't know what does. Pat. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
I have just asked, who will benefit from it. No one answered "I will" -- everyone who makes Unicode support believes that it will benefit someone else. I thought I did. OK, let me restate: I will! I actually do already because I did some work and it is in the ports. OK, I didn't say anything ealier because I though it was fairly obvious that anyone dealind with a *mixed* environment beyond that of ISO 8859-1 (even if that means just a mixture of ISO 8859-1/2) would find Unicode support in the kernel a blessing from the heaven. Let me restate that: I will use it. Currently, if you have a group of ISO 8859-2 users on the system , the ISO 8859-1 people see them as meaningless junk. I don't even want to think about something like Arabic. Pat. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Whatever happened to TenDRA?
Hmm. So I've compiled the TenDRA port, and I'm toying around with it, trying to get it to compile Qt (and perhaps gnu's libstdc++), but not suprisingly it seems to dislike some of the more basic (QList and QString and other template stuff) code in Qt, meaning even something as simple as moc can't be compiled. So off I went to the TenDRA web page, but it seems to be down (can't connect, etc). Has development on this compiler stopped or what? The project has been discontinued by DRA. I've set up a mirror of the site (as it was last avaliable) at http://siliconbreeze.com/TenDRA/. Hope it's of some help. Pat. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not gzip iso images?
On Wed, 15 Mar 2000, Sheldon Hearn wrote: And you're forgetting that, as I said in my original reply, people with 56K modems usually benefit from hardware compression over their link anyway. But you're defeated by your own argument, as according to you the image doesn't compress very well, and I suspect (in fact I know) that hardware compression at the modem is not as efficient as gzip -9 ... at best you might be able to get that 22Mb we're talking about saving, down to a 10Mb saving... you're still leaving the guy with the modem sat there for around 45 minutes... Remember that our modem guy has spent the last 48 hours sitting there waiting for the download to complete. I'm sure that by now he's fallen asleep and the 45 minutes will not make a difference anyway. ;) In most places that are ``affected'' by that 20MB you're trying to save, bandwidth is so expensive that you'll never going to download the ISO image anyway. I've just calculated that it would cost me AUD 120 or so, compared to $20 for downloading just the distribution I need. If I was to download the ISO image over my modem, I'd order a CD today instead (or enroll at Uni ;) So I'm supporting uncompressed iso images. 99.99% of those who'd benefit from the compression would never consider downloading them anyway, and 99.99% of those who are going to use these images will find .gz a pain. Pat. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk ZadarnowskiUniversity of New South Wales [EMAIL PROTECTED] School of Computer Science and Engineering -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 5.0 features?
Mark Hittinger writes: Something that the old DEC took a few stabs at was the idea of a "checkpoint" feature where a process or a series of processes could be put in a quiesced state. This would page out the process or processes into the swap space, allow a hardware shutdown, and after a reboot allow the restart of the checkpointed process(es). I did something like this for Philips while I was at UniSoft. It depended on some special hardware features (turning off/losing power generated an interrupt, there was a small UPS in the box along with battery-backed SRAM to save various kernel structures). Turning off the power caused all memory to be saved to disk (the kernel turned off the UPS after it was done). Upon a restart the kernel noticed that memory had been saved, read the contents in from disk, futzed around with some structures, and restarted what was curproc at the time of shutdown. It even worked ;-) Philips never did anything with it. Out of pure curiosity, what did you do with pending interrupts, partially completed DMA transfers and other such state information? Pat. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Patryk Zadarnowski [EMAIL PROTECTED] University of New South Wales -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Sun, 20 Feb 2000, Patryk Zadarnowski wrote: On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote: One more thing about GPTs (I thought I'll leave that till last. ;) Jochen Liedtke holds a German patent on them, although he will probably be fairly easily convinced to give FreeBSD rights to use them. I'll be happy to ask (if we're interested.) It looks like the hardware has to implement GPTs and know how to walk them. How can FreeBSD use them without hardware support ? No it doesn't. We've got software GPT implementations for both MIPS64 and Alpha, and they're both peform very well in our somewhat hostile SASOS conditions. So you have custom PALcode for Alpha on SASOS? We have been able to use OSF1 PALcode up to now which makes life a lot easier for supporting new hardware. Sure. Mungi (our SASOS) runs on top of an L4 microkernel. If anything, it improves portability: porting Mungi from MIPS to Alpha took literally few hours of working out endianess-related bugs ;) (tell me the same about FreeBSD ;P Of course using OSF1 PALcode simplifies life for FreeBSD, but it's really not an option for our OS research. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
:Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces :and it turns out that hash tables perform quite poorly. I'd suggest GPTs :instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW. :Both have the advantage of supporting multiple page sizes that IA64 (and :Alpha) offer, and hence dramatically increasing the TLB coverage over what :Linux (or any other commercial OS that took a bite at IA64) can achieve. :Kevin's paper's at: :ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Elphinstone:phd.ps.gz : :Maybe that way we can somehow make use of the Itanium's 4GB page size ; : :Pat. Linux has a good idea re: mapping all of real memory into KVM, it's just one that doesn't work well on a 32 bit architecture :-). But on a 64 bit architecture it can be seriously useful. At the very least we can get rid of the private pmap pages and make pmap copying a much faster operation. Actually, on IA64 this is not needed at all. The thing is, we've got eight regions accessible simultaneously (sort of like MIPS address space regions, only fully configurable, with per-region page table), so we can always reserve region 0 for user space, 1 for shared libraries, 2 for physical memory and 3 for KVM, and maybe even disable the page table for region 2, and use Keys to grant physical memory access permissions on demand. That way we don't waste TLB (umm... TC) entries for essentially one-to-one mappings. I read Kevin's thesis. Facinating! The GPT concept is essentially What is even more fascinating about IA-64 that the software TLB that Kevin describes in his thesis can be walked in hardware, and hence can cache variable page sizes (although unfortunately not all the IA-64 pages sizes are supported by VPHT) The only other architecture that offers that is SPARC, but their software TLB supports only 4KB and 64KB page sizes, so all other pages must be reloaded directly from the page table. a radix tree (and a degenerate version of the radix tree is, of course, the normal two-level page table IA32 uses). All the memory and performance issues Kevin brings up are exactly the same memory and performance issues that a radix tree has. And he is bang-on in regards to node sharing. With a normal page table node sharing is What's funny is that nobody (to the best of my knowledge) had the guts to implement node sharing or even variable page sizes in GPTs. They're a nightmare to code. Did I mention that we've been using them on MIPS and Alphas for few years now in our research SASOS? (and a few months on StrongARM, and soon on SPARCs ;) So they are field tested, and not just some piece of benchmark-based theorising. difficult because each page in the page table represents a large area of memory (4MB on IA32). But using a GPT we can potentially node-share the bulk of the pages associated with shared libraries despite there being COW'd pages in the middle of that space from the dynamic linking. LPCtires look even better. Have a look at http://www.cse.unsw.EDU.AU/~cls/cls.thesis.ps.gz they're designed *specifically* to promote variable pages sizes, and Chris claims that adding node sharing to his current implementation (he's got an almost-generic one that works on MIPS 4K, all Alphas and theoretically SPARCs) would be trivial. One more thing about GPTs (I thought I'll leave that till last. ;) Jochen Liedtke holds a German patent on them, although he will probably be fairly easily convinced to give FreeBSD rights to use them. I'll be happy to ask (if we're interested.) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Sun, Feb 20, 2000 at 01:48:49PM +1100, Patryk Zadarnowski wrote: It looks like the hardware has to implement GPTs and know how to walk them. How can FreeBSD use them without hardware support ? No it doesn't. We've got software GPT implementations for both MIPS64 and Alpha, and they're both peform very well in our somewhat hostile SASOS conditions. I'm not sure why you think that a hardware walk is necessary: For performance reasons and memory efficiency reasons. My understanding of We must be careful here. Although you're getting a samll immediate performance gain by not flushing the pipelines, the performance is killed if the working set is larger than the TLB (as it usually is on a moderately-loaded system, especially in presence of heavy IPC (eg. UNIX pipes)), in which case a smarter data structure will usually increase the TLB coverage. And don't forget that with VHPT you'll be getting nested TLB faults quite frequently in a sparsely-populated page table (think shared libraries). Efficiency-wise, Kevin has shown that you only need a fairly small VPHT, and it is global, so you ammortise the cost across all running tasks. Further, you can easily share a GPT or LPCtrie subtrees, at which stage the whole memory-wastage argument goes completely out of the window (I'm currently writing a microkernel that is intended to demonstrate just that on UltraSPARC which has an MMU vaguely resembling that of IA-64.). Besides, doesn't Linux duplicate the structure anyway even when it uses a hardware-walked page table? Avoiding data duplication isn't always a good thing: as a rule, caching helps. ;) your proposal is - use VHPT as a large in memory TLB and use GPT as operating system's primary page table. Precisely. Doesn't that involve duplication of information in memory, especially if the hash table is big ? No, not significantly, for two reasons: first, you don't need a huge VPHT -- 512KB is more than enough. Also, VPHT becomes a cache for the actual page table. It's been empirically demonstrated that 64 bit (esp. sparse 64 bit) page tables really need such a cache (software TLB) anyway. And it's the main way Intel planned VPHT to be used in the first place. The performance improvement tends to be significant (look at Kevin's PhD that I've posed before.) Besides, the amount of space saved due to a smarter page table data structure more than compensates for the additional memory anyway. the only reason why IA-64 walks VPHT in hardware *at all* is to minimize the impact on the pipeline and improve ILP: I think that's an important reason. A software only TLB miss handler would be inferior to a VHPT based solution on IA-64, IMO. It's the only justification Rumi Zahir (head of the IA-64 team) gave me when I was complaining about it. (as in: ``why bother? 64 bit page tables are an open problem and no other 64 bit platform I know of provides a hardware page table walk''. BTW, does anoone know if HP-PA and IBM 64bit PPC implement a hardware PT walk? Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
You're being just plain silly. It takes about 5 minutes with the manuals to realize just how little AXP and IA-64 have in common: one is a classic superscalar out-of-order design, the other is just about the opposite: a typical explicit-ILP architecture. What makes IA-64 great is the 8 years of statistical analysis of real-life software the architecture design team spent fine-tuning the instruction set. What makes AXP great is the clock rates Digital/Compaq manages to pump into the beasts ;) What makes IA-64 great is the fact that it has not been deployed, so Intel can say whatever it pleases them. If you got REAL LIFE NUMBERS, based on REAL LIFE PERFORMANCE, then we can talk. Let's see how it does Quake, then we can talk. This is rapidly becoming a stupid flame war so in the interest of keeping the list on-topic, I won't be replying publically to this thread from now on. ;) I *do* have some performance figures, as Intel has had the silicon for over six months now, but, of course, Intel being Intel, their lawyers keep everything under a wrap for now. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
:... :and Linux essentially treats hardware page tables as TLBs. : :The problem with the above approach is duplication of information between :Linux page tables and hardware page tables and inefficient use of memory :for page tables. : :I think OSes like FreeBSD which don't have a concept of machine independent :page table are essentially free to do anything in the hat layer and thus :have more flexibility. If I understand the hardware hash table method correctly, then I think the absolute best choice for FreeBSD is to use that method as it will allow us to get rid of the scaleability problems we have with the pv_entry_t scheme we use for IA32. The number of pv_entry_t's in an IA64 architecture wind up being fixed. How big can we make the hardware-assisted hash table? Also, a hash table scheme is a much better fit for a 64 bit address space model, especially with sparse mappings. The MIPS R4K and later all use a hash table scheme and it seems to work well for them. Kevin Elphinstone did a PhD thesis on TLB structures for 64 bit address spaces and it turns out that hash tables perform quite poorly. I'd suggest GPTs instead, or maybe LPCtrie that Chris Szmajda has been working on here at UNSW. Both have the advantage of supporting multiple page sizes that IA64 (and Alpha) offer, and hence dramatically increasing the TLB coverage over what Linux (or any other commercial OS that took a bite at IA64) can achieve. Kevin's paper's at: ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/Elphinstone:phd.ps.gz Maybe that way we can somehow make use of the Itanium's 4GB page size ; Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Just read this article: http://www.zdnet.com/zdnn/stories/news/0,4586,2440002,00.html Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Considering the fact that Intel released the IA-64 OS info only on the 15th, and, to my knowledge, haven't signed any NDA's with anyone from the FreeBSD team, I'd assume that we're precisely nowhere. ;) Having said that, I'll be getting Itanium hardware fairly soon after it's avaliable outside of Intel, and would be ultra-happy to work on an IA-64 FreeBSD when that happens. In the meantime, the only alternative would be to convince Intel to give someone their IA-64 SimOS, but there's an extermely slim chance of that happening (from talking to someone on the IA-64 team.) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Patryk Zadarnowski wrote: FreeBSD when that happens. In the meantime, the only alternative would be to convince Intel to give someone their IA-64 SimOS, but there's an extermely slim chance of that happening (from talking to someone on the IA-64 team.) An alternative to IA-64 is the alpha processor. Last time I checked, FreeBSD ran just peachy on a 64-bit processor. ;-) Check out Cmpaq's test drive program. I don't know... I'm still to get it to boot on mine (NetBSD runs fine, but for some bizzare reason, FreeBSD insists on a serial console ;) Anyway, alphas are boring compared to Itanium. What else can you say about a chip with 3MB of L3 cache on the die, a four clock cycle latency to carry the signal from one end of the chip to the other, and the main design limitation being the US power supplies? :) Not to mention the fact that Intel isn't even planning to release any single-cpu system Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
Which leads to my potentially ignorant question: Where is FreeBSD w/regards to running on the Itanium (or other 64bit chips)? Waiting for somebody at Intel to give us either hardware or simulator time. Without either of those things, "working on" Itanium support is a pretty pointless exercise. Just a thought: One could use the released 64-bit Itanium gcc, create a i386-itanium crosscompiler, and start preparing some stuff? Marco van de Voort ([EMAIL PROTECTED]) http://www.stack.nl/~marcov/xtdlib.htm The difficult bits rarely have anything to do with compilers and such (especially given that most of the code has been through a 64-bit port to the alpha). The system-mode pieces of IA-64/Merced were not public until recently; I noticed the full document set just became available on the intel web site this week. There's also the Linux port that was posted to the web in the past week or two; that should show what's needed for a FreeBSD port. The Linux port is extremely minimalistic and uses the minimum amout of IA-64 features to get the OS to do anything useful. Of course, as was mentioned before, without hardware or a simulator it's pretty pointless to put much effort into something like this. Also, you'll find that the actual silicon is somewhat different from the documentation: whole chunks of the architecture are either unimplemented or covered by errata, and not planned to be fixed in the public Itanium silicon. The OS teams that signed NDAs with Intel (including the Linux team: most of their code has been written by IA-64 teams at Intel and HP) have been cooperating very closely with Intel and were given a lot of information that (most of us) can only dream about. That is to say: even the simulator wouldn't help much right now. On the other hand, IA-64 is a very exotic architecture from the OS's point of view, and anyone planning to port *BSD to it should probably start planning ASAP. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
"I could have had a PA-8600!"? Today, and not at some vague point in the future? That sort-of misses the point, as I'm taking a research OS perspective, where IA-64 is trully unique in terms of versitality and a well thought-through design (especially when it comes to SASOS support!) Besides, that point in the future is not all that vague at all ;) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
What can one say to that, apart from "I have one right here and it works just fine" - not something you can say about the IA-64. 8) I'll just reach down and pat my trusty pair of manufactured-in-1993 Alpha 3000's on their heads... :) Oh, forgot... It's not new until Intel does it... sorry... mike You're being just plain silly. It takes about 5 minutes with the manuals to realize just how little AXP and IA-64 have in common: one is a classic superscalar out-of-order design, the other is just about the opposite: a typical explicit-ILP architecture. What makes IA-64 great is the 8 years of statistical analysis of real-life software the architecture design team spent fine-tuning the instruction set. What makes AXP great is the clock rates Digital/Compaq manages to pump into the beasts ;) And no, there's nothing fundamentally new in IA-64 apart from the fact that they're the last kids on the block with a 64 bit chip ;) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.
Recently I was tasked to find a way to scale up our MYSQL server, running MYSQL3.22.15 on FreeBSD3.3. I've been testing a hardware RAID solution, and found that with 6 disks in a RAID5 configuration, the system was only perhaps 30% faster than when running on a single disk. [The 6 disks in the RAID5 are the same model as the single-disk test I was comparing against.] Experimentation determined that pthreads was the problem. FreeBSD's implementation of pthreads using a select() loop, and select() always says that disk I/O is ready to proceed, and disk I/O never return EWOULDBLOCK. Essentially, pthreads was serializing the MYSQL read() requests, and if the dataset exceeds memory size, performance becomes entirely seek bound. I've implemented a rough fix, which is to rfork() processes which I label "iothreads" to handle the disk I/O. The parent process running pthreads has a socketpair() to each of the iothreads. The iothreads wait for requests on the socketpair, and since socketpairs can block, pthreads can handle them efficiently. This essentially allows me to turn blocking disk I/O calls into non-blocking calls. Having multiple pending seeks turns out to be a huge win for MYSQL, allowing it to scale much better as disks are added to the RAID5 array. Unfortunately, I'm concerned about using this code in production, because it needs a fair amount of cleanup to handle signals and administrative functions correctly. For this reason and others, I'm starting a project to move it into the pthreads library itself. Before I embark on that effort, I have a couple questions: 1) Does this seem like a reasonable approach? [It _works_, and well. But it tastes strongly of hack.] 2) Does anyone have suggestions for a solution that will be cleaner and won't take man-months to implement? [Which is the redeeming quality of what I've got - it took me two days to zero in on a very workable solution.] 3) Is anyone working on something I might leverage off of in this area? [For instance, a select()-based interface to async I/O? Or support for blocking disk I/O in select() and read()?] 4) Is there anyone willing to commit to testing my modified pthreads library against MYSQL? [I'll be stress testing it quite heavily, of course. It would probably also be testable against Squid with async I/O and multithreaded Apache 2.0.] I'm no expert on pthreads, but, if you decide to proceed with implementing a mixed user-land/rfork pthread implementation, may I suggest that you implement is through POSIX pthread_attr_setscope() interfaces instead of some local extension. pthread_attr_setscope() sounds like a portable interface to precisely what you're trying to achieve. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
Hi, is there any alternative (non-commercial) C compiler to use, or is gcc the best? I have just upgraded my system to -current w/egcs 2.95.2 and I have several problems with it, especially when using optimizations (-O2 and such) ok I know there's the good old gcc 2.7.2.3 but a good BSD-licensed compiler would be nice =) Check out TenDRA in the ports tree. Unfortunately, most ppl tend to use GCC extensions a lot, so you won't be able to replace gcc, but TenDRA certainly is a solid alternative. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
On Wed, 5 Jan 2000, Patryk Zadarnowski wrote: Hi, is there any alternative (non-commercial) C compiler to use, or is gcc the best? I have just upgraded my system to -current w/egcs 2.95.2 and I have several problems with it, especially when using optimizations (-O2 and such) ok I know there's the good old gcc 2.7.2.3 but a good BSD-licensed compiler would be nice =) Check out TenDRA in the ports tree. Unfortunately, most ppl tend to use GCC extensions a lot, so you won't be able to replace gcc, but TenDRA certainly is a solid alternative. With the understanding that using Tendra just for the kernel will be painful, but (if you're determined) doable. If you want it for building world, you better make prior reservations at the local mental health clinic, because YOU WILL NEED IT before you get that done. Certainly, although it's still probably the only trully-free C compiler around, and definitely the only more-or-less-free ISO C++ compiler. If anyone is interested, the main TenDRA web site has been down for a while, so I've set up a mirror at http://siliconbreeze.com/TenDRA/. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
In the last episode (Oct 29), Lars Gerhard Kuehl said: Think about it for a second. How big is a pointer? The Intel architecture still supports segmented memory, so the effective maximum pointer size is 48 bit. The extra 16 bits of the segment don't actually contribute to the address space size on IA32, as Intel decided to do segment translation before virtual address translation (ie, all segments have to fit in the same 32bit vaddr space). PPC, on the other hand ;) If you want a trully gigantic address space, try a 64 bit PPC, it's got 80 bit addresses, even if they're totally and utterly useless unless you're writing a SASOS. Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: updating packages automatically...
On Sat, 25 Sep 1999, Chris Costello wrote: Aah! No! I tried that with GNOME once and it drove me insane for about two weeks. Auto-upgrades on ports would be _very_ _very_ bad, especially for those using apache from ports! that's right. i thought about having some kind of exclude list for ports that shall never be upgraded automatically. anyway, the script will just generate a shell script output. it should not replace packages without manual intervention. If most FreeBSD users are like me, you should set up an include list instead. Then, it could actually be sort of useful. Most people would use it to auto-upgrade packages for beta and other unstable software. However, I think that an /etc/periodic/weekly script that reports on which packages are outdated in the weekly report would be a much more welcome utility ;) Pat. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: style question
I'm looking at cleaning up a few compile nits and I'm wondering what the
officially approved way of silencing "may not be used" warnings:
int
foo(int flag)
{
int j;
if (flag)
j = 1;
/*
* This noop statement is enough to confuse the optimiser so it
* forgets that j is initialised iff flag != 0
*/
flag = !!flag;
I don't know about the "official" way to silence the compiler (a well
placed else statement or a "default" switch case usually does the
trick for me) That is to say, I'm willing to argue that fixing the
flow of control is the only clean way of getting rid of these
warnings, unless you know something special about the allowed values
of the offending variable (eg. you know that your switch case is
exhaustive), in which case a dummy "default" or initializer cannot
hurt you much.
Also !!x IS NOT a noop. For example, !!5 == 1. I think you meant to
say `flag = ~~flag', which indeed is a NOP.
Pat.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: style question
I'm looking at cleaning up a few compile nits and I'm wondering what the
officially approved way of silencing may not be used warnings:
int
foo(int flag)
{
int j;
if (flag)
j = 1;
/*
* This noop statement is enough to confuse the optimiser so it
* forgets that j is initialised iff flag != 0
*/
flag = !!flag;
I don't know about the official way to silence the compiler (a well
placed else statement or a default switch case usually does the
trick for me) That is to say, I'm willing to argue that fixing the
flow of control is the only clean way of getting rid of these
warnings, unless you know something special about the allowed values
of the offending variable (eg. you know that your switch case is
exhaustive), in which case a dummy default or initializer cannot
hurt you much.
Also !!x IS NOT a noop. For example, !!5 == 1. I think you meant to
say `flag = ~~flag', which indeed is a NOP.
Pat.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Intel Merced FreeBSD???
On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote: Thomas David Rivers wrote: Microsoft needs a "business quality" version of Windows, which it claims is Windows/2000. That version of Windows could benefit from a 64-bit port, if for marketing only; but I don't think it would result in the volume of sales Intel is looking for. A funny thing is that Microsoft is porting essentially a 32-bit version of Windows to Merced. All the programs for Windows that want to use 64-bit support will have to be modified because the MS compiler defines both int and long as 32-bit. On the other hand the Unix compilers (at least UnixWare and as far as I understood that's the common Unix convention) provide a mode with 64-bit longs that gives certain degree of 64-bit awareness just by recompiling. I'm yet to see a 64 bit long on a 32 bit OS. It would be brain-dead, IMO, especially as longs are typically assumed to be as fast as ints. However, most Unix programs are (should be?) designed with portability in mind, and that means making no assumptions about sizeof(long). That's what makes porting U*ix to 64 bit so much easier than porting Wheenbloze In the later, everyone thinks that they know every petty detail of the architecture, often down to exact values of pointers.. Incidentally, Windows CE has been running on a 64 bit CPU for quite a while (MIPS R4K), although MIPS went out of its way to make R4K 32bit-compatible at least in the userland. Patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel Merced FreeBSD???
On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote: Thomas David Rivers wrote: Microsoft needs a business quality version of Windows, which it claims is Windows/2000. That version of Windows could benefit from a 64-bit port, if for marketing only; but I don't think it would result in the volume of sales Intel is looking for. A funny thing is that Microsoft is porting essentially a 32-bit version of Windows to Merced. All the programs for Windows that want to use 64-bit support will have to be modified because the MS compiler defines both int and long as 32-bit. On the other hand the Unix compilers (at least UnixWare and as far as I understood that's the common Unix convention) provide a mode with 64-bit longs that gives certain degree of 64-bit awareness just by recompiling. I'm yet to see a 64 bit long on a 32 bit OS. It would be brain-dead, IMO, especially as longs are typically assumed to be as fast as ints. However, most Unix programs are (should be?) designed with portability in mind, and that means making no assumptions about sizeof(long). That's what makes porting U*ix to 64 bit so much easier than porting Wheenbloze In the later, everyone thinks that they know every petty detail of the architecture, often down to exact values of pointers.. Incidentally, Windows CE has been running on a 64 bit CPU for quite a while (MIPS R4K), although MIPS went out of its way to make R4K 32bit-compatible at least in the userland. Patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3 - 2
4,5,6,7 - 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
Nick,
Probably the best solution I can think of is a binary search on the
number. I'd estimate it as better than a table, as you save on memory
references (tables sound cool, but, from experience, they cause enough
extra data cache misses to kill any advantage, even in
a highly-optimized inner loop.
For 8-bit integets, a quick solution is:
int
round_up(int x)
{
if (x 0xf0) {
if (x 0xc0)
return (x 0x80) ? 0x80 : 0x40;
else {
return (x 0x20) ? 0x20 : 0x10;
}
}
else {
if (x 0xc)
return (x 0x8) ? 0x8 : 0x4;
else {
return (x 0x2) ? 0x2 : 0x1;
}
}
}
It's actually faster than the BSF/BSR operations on Pentium (and the
ffs() libc function), as Pentium does a sequential search of the bit
string and therefore is O(n) (eek!)
The innermost comparison could probably be avoided if it wasn't 00:37
or if I didn't have to get up early in the morning. You could also
combine that with a smaller lookup table to get the best of both
worlds.
Patryk.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: from number to power of two
Does anyone know an inexpensive algorithm (O(1)) to go from an number to
the next (lower or higher) power of two.
1 - 1
2,3 - 2
4,5,6,7 - 4
8,9,10,11,12,13,14,15 - 8
etc.
So %1101 should become either %1 or %1000.
The only solution I have so far is a table. That is a possibility as the
the highest number will be 32 I think.
Nick,
Probably the best solution I can think of is a binary search on the
number. I'd estimate it as better than a table, as you save on memory
references (tables sound cool, but, from experience, they cause enough
extra data cache misses to kill any advantage, even in
a highly-optimized inner loop.
For 8-bit integets, a quick solution is:
int
round_up(int x)
{
if (x 0xf0) {
if (x 0xc0)
return (x 0x80) ? 0x80 : 0x40;
else {
return (x 0x20) ? 0x20 : 0x10;
}
}
else {
if (x 0xc)
return (x 0x8) ? 0x8 : 0x4;
else {
return (x 0x2) ? 0x2 : 0x1;
}
}
}
It's actually faster than the BSF/BSR operations on Pentium (and the
ffs() libc function), as Pentium does a sequential search of the bit
string and therefore is O(n) (eek!)
The innermost comparison could probably be avoided if it wasn't 00:37
or if I didn't have to get up early in the morning. You could also
combine that with a smaller lookup table to get the best of both
worlds.
Patryk.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: quad_t and portability
In message pine.bsf.4.10.9908070138180.9444-100...@janus.syracuse.net Brian F. Feldman writes: : You can always use off_t with %qd, (int64_t)foo. But that isn't portbale. %qd is a bsdism. %lld and %llu are the latest C standards way to say that. If you're that fixed on portability, %lux%08ulx, (long)foo32, (long)foo is always a perfectly-portable option (or %lud%08ud, (unsigned long)foo / UL, (unsigned long)foo % UL if you insist on decimal output; you'll need to watch the signs if you want to use longs instead of unsigned longs, but it's only mariginally more complicated). I doubt that the cost of splitting foo into two would be significant considering that it is split up into digits inside printf() anyway (it might actually be faster on some architectures). l8r, patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: quad_t and portability
In message [EMAIL PROTECTED] "Brian F. Feldman" writes: : You can always use off_t with "%qd", (int64_t)foo. But that isn't portbale. %qd is a bsdism. %lld and %llu are the latest C standards way to say that. If you're that fixed on portability, "%lux%08ulx", (long)foo32, (long)foo is always a perfectly-portable option (or %lud%08ud", (unsigned long)foo / UL, (unsigned long)foo % UL if you insist on decimal output; you'll need to watch the signs if you want to use longs instead of unsigned longs, but it's only mariginally more complicated). I doubt that the cost of splitting foo into two would be significant considering that it is split up into digits inside printf() anyway (it might actually be faster on some architectures). l8r, patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Swap overcommit
At 9:52 PM -0700 7/15/99, Matthew Dillon wrote: : ... How many programmers bother to even *clear* errno before : making these calls (since some system calls do not set errno : : if it already non-zero). Virtually nobody. : ^^^ : :Erm... WTF?!?! If so, why the HELL are we doing that?!? No, wait, I got that wrong I think. Oh yah, I remember now. Hmm. How odd. I came across a case where read() could return -1 and not set errno properly if errno was already set, but a perusal of the kernel code seems to indicate that this can't happen. Very weird. For what it's worth, I know I've run into situations where errno had to be cleared before calling some system routine (but I don't think it was read, and I am sure it wasn't on freebsd). Ahem, I'm not sure what that's got to do with swap overcommit, but anything to distract this thread is a good thing ;) The correct thing to do with errno is to clear it before a call IFF you are going to check its value on return from the call, simply because the calls NEVER don't clear errno on success, but set/change it on error. Every standard I've seen requires this behaviour quite explicitely, and I'm preaty sure it's documented someone in BSD man pages too. It's definitely correct if you look at the syscall stub code in libc. And yes, almost all the code I've seen does the right thing when it comes to handling errno, including checking its value on an error from system call (ususally by calling warn() or err()), so the ``Virtually nobody'' argument above is rather misguided. If something in libc READS errno without clearing it (other than err/warr functions that is ;), it's badly broken and should be fixed in the library, not in the user code. IMHO. patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
[EMAIL PROTECTED] (Julian Elischer) writes: we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) patryk. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
jul...@whistle.com (Julian Elischer) writes: we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) You can't extend the address space that way, segments are all parts of the single 4GB address space described by the page mapping. True, but you can reserve a part of the 4GB address space (say 128MB of it) for partitioning into tiny (say 8MB) address spaces (which are still flat, just small), for use by small processes, the idea being that all those small processes will than share a single page table without compromising on memory protection (the GDT is under full OS's control anyway), or the simplicity of a flat address space (virtual addresses still start at 0 and continue till the top of address space; the scheme is totally transparent.) patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
Why not put the kernel in a different address space? IIRC there's no absolute requirement for the kernel and userland to be in the same address space, and that way we would have 4 GB for each. Wouldn't that make system calls that need to share data between kernel and user spaces hopelessly inefficient? Things like sysctl() would need to introduce (temporary) memory mappings, and someone would have to keep track of these mappings and remove them as required, or the kernel would probably run out of address space in no time, given even with 4GB to spare. On top of that, every mapping established requires some messing arround with the TLB, which, at least on pentium, is rather expensive. Incidentally, someone already experimented with such dual address spaces on Linux, and the result was a 30% or so slow down. If you're interested, I can give you the relevant references (the scenario was somewhat different, but the source of the performance hit was the dual address space.) patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Bursting at the seams (was: Heh heh, humorous lockup)
we already use the gs register for SMP now.. what about the fs register? I vaguely remember that the different segments could be used to achieve this (%fs points to user space or something) ... as I've suggested a few days ago, and was told to shut up with a (rather irrelevant) reference to SASOS's. It can be done, in fact, it's already been done, with 50%+ performance improvement for tasks that rely heavily on IPC. (think client/server; email me for references.) However, it would involve a rather major redesign of the MMU and some redesign of the syscall stack. Further, one ends up restricting the size of the address space, which is fine until you start loading dynamic libraries. With something like libc, the working set may be small if all you need is a few system call stubs, but you end up with an extremely sparse address space which cannot be handled well with segmentation. Incidentally, you don't need to use FS to implement a tagged TLB using Liedtke's small address spaces. All you need is to modify CS, DS and SS; noone in the unix world relies on the values of ES and FS anyway; if they do, a quick-and-easy segmentation fault will teach them a lesson preaty fast. ;) patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: support for i386 hardware debug watch points
I've got some prototype code in place which supports the context switching part of this. It's pretty simple right now, as I'm trying to keep changes to a minimum. What I've done is simply added the dr0-dr3,dr6,dr7 registers to 'struct pcb' in /usr/src/sys/i386/include/pcb.h. In cpu_switch(), during a save operation, I load %dr7, and check the lower 8 bits, which indicate if any breakpoints are in use. If they are, I save all the debug registers, then clear out %dr7, which disables the breakpoints. During a restore operation, I load the value of %dr7 from the pcb structure of the new process, and if any of the lower 8 bits are set, I restore all the debug registers. This is not as efficent as it could be implemented with a separate flag to indicate whether saving the debug registers is necessary since loading/storing the debug registers is fairly expensive (11 clocks on an i486). 22 clocks on i386, 10 on i486, 11 on pentium. Also, on another topic, DRs are fairly portable as they've been a part of IA32 since i386. Comments? I'm no expert on FreeBSD kernels, but I can speak for L4, and it's always good to look at past experiences in the area. (L4 is a very lean microkernel running on x86's, MIPS, (and soon Alphas and ARMs, although I'm currently in a process of convincing the authors of the later two to use BSD lincence instead of GPL ;) It currently claims to have the fastest IPC and lightweight thread implementation, so I guess it's a good raw model.
Re: environment strings
I know about envp.
What I want to know is the exact position of these variables on the stack.
and if anywhere I can find some data, on the exact compisoition of the
stcak, then it will be very helpful.
references of books and websites wil be most helpful.
Basically, i386 BSD kernels (you're after i386, aren't you?) point ESP to
the following "struct" (which means that it will be dumped at the very
top of the address space)
struct kframe {
int argc; /* "argc" to be passed to main() */
char *argv[argc]; /* "argv" to be passed to main() */
char *null; /* a NULL pointer terminating argv[] */
char **envp;/* value to be assigned to "environ" */
};
/usr/src/lib/csu/i386/crt0.c is probably the best reference you can get
your hands on ;)
Patryk.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: environment strings
I wanted t know where the environment strings i bsd were stored after a program execs another one. extern char **environ; At the top of memory. You can access them by the standard (but undocumented) method: int main (int argc, char *argv [], char *envp []) envp is a pointer to the environment strings. This is true for every version of UNIX I know. This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). Besides, the `envp' argument is a recommended extension in ISO/ANSI C, so you can hardly say that it's undocumented. l8r, patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
This is of course correct except for the `undocumented' claim. The `envp' has been documented as the third argument to main() since the Pharaons (well, not quite ;). Apparently ATT UNIX even has a (documented) five-parameter main(). This is news to me. Can you point to the documentation? I'll sniff around and get back to you (read: I'll ask our local guru on PDP-11's and other ancient rituals, who told me about those in the first place.) l8r, patryk. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: environment strings
I know about envp.
What I want to know is the exact position of these variables on the stack.
and if anywhere I can find some data, on the exact compisoition of the
stcak, then it will be very helpful.
references of books and websites wil be most helpful.
Basically, i386 BSD kernels (you're after i386, aren't you?) point ESP to
the following struct (which means that it will be dumped at the very
top of the address space)
struct kframe {
int argc; /* argc to be passed to main() */
char *argv[argc]; /* argv to be passed to main() */
char *null; /* a NULL pointer terminating argv[] */
char **envp;/* value to be assigned to environ */
};
/usr/src/lib/csu/i386/crt0.c is probably the best reference you can get
your hands on ;)
Patryk.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
