Re: [9fans] 8 cores
Iruata Souza wrote: On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman [EMAIL PROTECTED] wrote: Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? only for the fun of it, I'm slowly trying to port it to my SGI O2. nice! whats the status of your port? have an SGI indy (IP22) and would like to contribute if i find the time :-) please put it somewhere! iru cinap
Re: [9fans] 8 cores
I could imagine that databases use mmap() havily it's a little mystery for me why they would do that since it's slower (or ought to be), because the trap path and fault recovery must do more work than syscall (perhaps much more). it's also difficult then to optimise the replacement strategy for the application without madvise calls (and you trust those implicitly?) but those are system calls that cost time.
Re: [9fans] 8 cores
Charles Forsyth wrote: I could imagine that databases use mmap() havily it's a little mystery for me why they would do that since it's slower (or ought to be), because the trap path and fault recovery must do more work than syscall (perhaps much more). it's also difficult then to optimise the replacement strategy for the application without madvise calls (and you trust those implicitly?) but those are system calls that cost time. makes sense of course... but at least mysql uses mmap() for some table types as a caching mechanism. http://www.mysqlperformanceblog.com/2006/05/26/myisam-mmap-feature-51/ this may just be an exception and real databases use read()/write() syscalls and implement the caching themself. but where should i know... i dont need/use databases and have not looked at the sourcecode of one. cinap
Re: [9fans] 8 cores
On Thu, 2008-07-17 at 10:07 +0100, Charles Forsyth wrote: I could imagine that databases use mmap() havily it's a little mystery for me why they would do that since it's slower (or ought to be), slower compared to what? I'd expect the biggest slowdown for read()/write() be not the price of a syscall, but what you pay for copying data in/out of the kernel. With mmap() there's no copying. Thanks, Roman.
Re: [9fans] 8 cores
On Wed, 2008-07-16 at 22:09 -0400, erik quanstrom wrote: On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote: coming as no suprise, the pc port of plan 9 does work just fine with 8 cores. mpls; cat /dev/sysstat 0 14271 21350133991116 0 0 0 99 0 Looking at the output 99% is idle time. Have you had a chance to look at this system when it is fully loaded with something meaningful? not really. a kernel compile from ramfs took about 2.9s with an average of more than 3s of cpu used for every second of real time. a compile from the fs over a gigabit link took about 1s longer, but used far less cpu. neither is particular impressive, but i'm not using a great percentage of the cycles available ( ~3/8) and i am using the slowest processor on the sheet and, due to my misreading of the datasheet, i have only half the memory channels populated. I see. did you have anything specific in mind? Not really, no. Most of the benchmarks that I'm familiar with would require a strong compiler support which is not (yet?) available on Plan9. Things like SPEC OMP and the like. I was looking more for a nice war story, I guess. Thanks, Roman.
Re: [9fans] 8 cores
On Thu, Jul 17, 2008 at 5:41 AM, erik quanstrom [EMAIL PROTECTED] wrote: as you've pointed out, performance-wise it's not copying vs. nothing it's copying vs page faults and trips through the vm code. i would think playing vm games (as linus likes to say) would make scheduling on mp harder But you make trips through the vm code on read/write in any event, don't you? There was a pretty good paper comparing these paths once and in the end it boiled down to your cost will vary depending on how you wrote the kernel :-) This problem has been worked for a long time by Sun among others. They've had several decades to think on it. ron
Re: [9fans] 8 cores
On Thu, Jul 17, 2008 at 11:07, Charles Forsyth [EMAIL PROTECTED] wrote: I could imagine that databases use mmap() havily it's a little mystery for me why they would do that since it's slower (or ought to be), because the trap path and fault recovery must do more work than syscall (perhaps much more). it's also difficult then to optimise the replacement strategy for the application without madvise calls (and you trust those implicitly?) but those are system calls that cost time. A much more important reason might be the fact that memory mapping of files is only one function of mmap() and company. Basically when you have mmap() and munmap() you can write your own allocator (which might be very useful, especially for databases). I won't delve into using it for I/O, but a specialized memory allocator can get you a big speedup - after all application developer knows the memory usage pattern of his app better than kernel/system library. Of course, that is assuming that the developer in question has a clue... -- Paweł Lasek
Re: [9fans] 8 cores
Well, depends. Non-mmap you have to do the storage management in the app. mmap, you're using the storage management in the kernel to figure out where the data goes, as well as all the LRU stuff to figure out what happens when you're running out of memory and you need to get rid of some of it.. Most kernels do a better job than most people at this sort of thing (at least from code I've seen). i haven't found this to be the case. in a former life, one i'd rather forget, i did full text search. in order to return the full text, we had to go get the document. due to the very crappy nature of ext2, it was not feasable to store the documents individually. they had to be bundled up in chunks of about 1gb. being young and easily distracted by shiny bits, i decided to use mmap. to my shock and horror, this turned out to be really slow. so then i modified the mmap to only map part of the file. this was faster, but the speed of this operation was strongly influenced by the size of the file. if i had been even moderately smart, i would have just read the part of the file i needed. it would have been much, much faster. as to using mmap for memory management, that confuses me. it's like saying the os should provide linked lists, because developers can't do it. isn't part of the argument here that applications know better how to manage buffers? personally, i suspect the reason the unix guys need mmap, is to support 100mb of shared libraries for firefox. if you want mmap, why not start over with something like multics. then you can get rid of the annoying file abstraction all together. (of course, disagreeing with ken can be a dangerous business.) - erik
Re: [9fans] 8 cores
On Thu, Jul 17, 2008 at 6:45 AM, erik quanstrom [EMAIL PROTECTED] wrote: i haven't found this to be the case. it's not always the case. in a former life, one i'd rather forget, i did full text search. in order to return the full text, we had to go get the document. due to the very crappy nature of ext2, it was not feasable to store the documents individually. they had to be bundled up in chunks of about 1gb. being young and easily distracted by shiny bits, i decided to use mmap. A very bad mistake for streaming data. as to using mmap for memory management, that confuses me. it's like saying the os should provide linked lists, because developers can't do it. isn't part of the argument here that applications know better how to manage buffers? In certain cases, the OS memory management for pages can be exploited and it can do a good job for you. Not in all cases of course. ron
Re: [9fans] 8 cores
On Thu, Jul 17, 2008 at 5:38 AM, Kernel Panic [EMAIL PROTECTED] wrote: Iruata Souza wrote: On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman [EMAIL PROTECTED] wrote: Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? only for the fun of it, I'm slowly trying to port it to my SGI O2. nice! whats the status of your port? have an SGI indy (IP22) and would like to contribute if i find the time :-) please put it somewhere! http://iru.oitobits.net/src/9sgi/ good to know someone's interested besides me and Tim Weiss. iru
Re: [9fans] 8 cores
On Wed, Jul 16, 2008 at 1:12 PM, Benjamin Huntsman [EMAIL PROTECTED] wrote: That being said, while huge scalability is certainly research-worthy, does anyone actually run anything on Plan 9 that needs or would otherwise benefit from 8+ CPUs and more than a few GB's of RAM? The Blue gene HPC folks come to mind. Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? Some people would like to, but to my knowledge fourth edition hasn't been ported to any other platforms. I've heard rumors of a near complete x86_64 port, and there's occasional interest in sparc and ppc ports. -sqweek
Re: [9fans] 8 cores
Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? yes: http://tinyurl.com/5jc8u8, for instance
Re: [9fans] 8 cores
Hi Mr Forsyth, I tried to respond to your directly, but the mail bounced. Here in Saudi Arabia tinyurl is blocked (by the govt). Is it possible that you (or someone else) can expand the URL for me and send it to me off-list? Thanks John Waters, No relation to the director On Wed, Jul 16, 2008 at 2:37 PM, C H Forsyth [EMAIL PROTECTED] wrote: Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? yes: http://tinyurl.com/5jc8u8, for instance
Re: [9fans] 8 cores
Some people would like to, but to my knowledge fourth edition hasn't been ported to any other platforms. Plan 9 has always run on multiple architectures, and the fourth edition is no different. ls /sys/src/9 will show you that there are ports to the Alpha PC (alphapc) the HP iPaq (bitsy), and a few PowerPC boards (mtx, ppc). Russ
Re: [9fans] 8 cores
For me the URL works out to: http://domino.research.ibm.com/comm/research_projects.nsf/pages/hare.index.html HARE! Awesome. Anthony
Re: [9fans] 8 cores
I'd like to ask a question, but before I do, feel I should say, I've been on this list long enough to understand that Plan 9 is a research vessel, not an OS that's targeted at commercial deployment... i can't agree with this label research os if you mean to imply that it's not stable or somehow unfinished. i run the company's infastructure on plan 9 and our main product — that is my paycheck — depends on plan 9. i spend a lot less time fixing things now than i did when i ran a different company's infastructure on aix and linux. i also suffer much less downtime. on the other hand, if by research os you mean simple and flexable, then i couldn't agree more. That being said, while huge scalability is certainly research-worthy, does anyone actually run anything on Plan 9 that needs or would otherwise benefit from 8+ CPUs and more than a few GB's of RAM? this style product will easily scale to that level http://tinyurl.com/5e3q9p [coraid.com] the real question is can you find a big enough chassis. if that doesn't compel you, running upas imap server for ~40 users with 1.3gb of inboxes might. since upas has the bad manners to load the entire mailbox, we're using about 90% of the 3.5gb bios will spare us in 32bit mode. i also watched it at 100% cpu for a solid hour yesterday. it's embarassing that mail is such a hog. this is our scalability plan: /n/sources/contrib/quanstro/src/nupas/ - erik
Re: [9fans] 8 cores
if that doesn't compel you, running upas imap server for ~40 users with 1.3gb of inboxes might. since upas has the bad manners to load the entire mailbox, we're using about 90% of the 3.5gb bios will spare us in 32bit mode. i also watched it at 100% cpu for a solid hour yesterday. There is supposedly an amd64 port somewhere which should let you use more ram, but you already know that. Of course we all also know how releasing code that people might find useful and even improve is a crazy idea... it's embarassing that mail is such a hog. this is our scalability plan: /n/sources/contrib/quanstro/src/nupas/ Agreed uriel
Re: [9fans] 8 cores
You could always import /net from a 9grid node in a (more) free country ;) (Maybe SA should start filtering 9P connections ;) Peace uriel On Wed, Jul 16, 2008 at 2:13 PM, John Waters [EMAIL PROTECTED] wrote: Hi Mr Forsyth, I tried to respond to your directly, but the mail bounced. Here in Saudi Arabia tinyurl is blocked (by the govt). Is it possible that you (or someone else) can expand the URL for me and send it to me off-list? Thanks John Waters, No relation to the director On Wed, Jul 16, 2008 at 2:37 PM, C H Forsyth [EMAIL PROTECTED] wrote: Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? yes: http://tinyurl.com/5jc8u8, for instance
Re: [9fans] 8 cores
I have a means to circumvent the filters, but not at my current location. Thankfully 9p flows as poorly as all the other protocols here in KSA, but it still flows. I wonder sometimes if I am the only plan 9 user in The Kingdom... Where most folks are accustomed to five nines of availability, the denizens of my hot/dusty/boring city are generally happy with five sevens. Getting back to the topic at hand, does anyone know any specific 8-core capable motherboards that are running plan 9 on bare metal? ma salaama jcw On Wed, Jul 16, 2008 at 4:44 PM, Uriel [EMAIL PROTECTED] wrote: You could always import /net from a 9grid node in a (more) free country ;) (Maybe SA should start filtering 9P connections ;) Peace uriel On Wed, Jul 16, 2008 at 2:13 PM, John Waters [EMAIL PROTECTED] wrote: Hi Mr Forsyth, I tried to respond to your directly, but the mail bounced. Here in Saudi Arabia tinyurl is blocked (by the govt). Is it possible that you (or someone else) can expand the URL for me and send it to me off-list? Thanks John Waters, No relation to the director On Wed, Jul 16, 2008 at 2:37 PM, C H Forsyth [EMAIL PROTECTED] wrote: Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? yes: http://tinyurl.com/5jc8u8, for instance
Re: [9fans] 8 cores
Uriel wrote: You could always import /net from a 9grid node in a (more) free country ;) (Maybe SA should start filtering 9P connections ;) Peace Glad to hear that device remoting has some practical applications :-) Given the US Department of Homeland Insecurity, we may need that in the US soon. Hopefully, the current regime will die a gruesome political death in the coming election.
Re: [9fans] 8 cores
i can't agree with this label research os if you mean to imply that it's not stable or somehow unfinished. Not at all. Just meant that one doesn't run their company's Oracle database on it. Not because it's not worthy of doing so, but such things just aren't compiled for it. ...you mean simple and flexable, then i couldn't agree more. And always trying to find the right or most elegant way to do things... Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? yes: http://tinyurl.com/5jc8u8, for instance Hadn't seen that before. Anyone know what cluster interface they're using? Thanks!! -Ben winmail.dat
Re: [9fans] 8 cores
On Wed, Jul 16, 2008 at 5:02 PM, Benjamin Huntsman [EMAIL PROTECTED] wrote: i can't agree with this label research os if you mean to imply that it's not stable or somehow unfinished. Not at all. Just meant that one doesn't run their company's Oracle database on it. Not because it's not worthy of doing so, but such things just aren't compiled for it. You might be able to run Oracle with linuxemu... if Firefox runs, anything can! uriel
Re: [9fans] 8 cores
On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote: coming as no suprise, the pc port of plan 9 does work just fine with 8 cores. mpls; cat /dev/sysstat 0 14271 21350133991116 0 0 0 99 0 Looking at the output 99% is idle time. Have you had a chance to look at this system when it is fully loaded with something meaningful? Thanks, Roman.
Re: [9fans] 8 cores
On Wed, Jul 16, 2008 at 2:12 AM, Benjamin Huntsman [EMAIL PROTECTED] wrote: Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? only for the fun of it, I'm slowly trying to port it to my SGI O2. iru
Re: [9fans] 8 cores
On Tue, 2008-07-15 at 18:28 -0400, erik quanstrom wrote: coming as no suprise, the pc port of plan 9 does work just fine with 8 cores. mpls; cat /dev/sysstat 0 14271 21350133991116 0 0 0 99 0 Looking at the output 99% is idle time. Have you had a chance to look at this system when it is fully loaded with something meaningful? not really. a kernel compile from ramfs took about 2.9s with an average of more than 3s of cpu used for every second of real time. a compile from the fs over a gigabit link took about 1s longer, but used far less cpu. neither is particular impressive, but i'm not using a great percentage of the cycles available ( ~3/8) and i am using the slowest processor on the sheet and, due to my misreading of the datasheet, i have only half the memory channels populated. did you have anything specific in mind? - erik
Re: [9fans] 8 cores
coming as no suprise, the pc port of plan 9 does work just fine with 8 cores. Just out of interest, what's the machine? winmail.dat
Re: [9fans] 8 cores
Which hardware platform is that? -mlw -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of erik quanstrom Sent: Tuesday, July 15, 2008 3:29 PM To: 9fans@9fans.net Subject: [9fans] 8 cores coming as no suprise, the pc port of plan 9 does work just fine with 8 cores. mpls; cat /dev/sysstat 0 14271 21350133991116 0 0 0 99 0 19116 1051772279 812 0 0 0 99 0 2 15142 10624035781298 0 0 0 99 0 39529 1028452663 644 0 0 0 99 0 4 15035 10898637171285 0 0 0 99 0 59054 1051842198 744 0 0 0 99 0 6 15222 10653236331217 0 0 0 99 0 79547 1032392525 868 0 0 0 99 0 this machine has more processor cache (24mb) than the entire unix room where i went to school. and it's only ½ of a 1u chassis. the other half, stpaul, has an identical configuration. - erik
Re: [9fans] 8 cores
add this one to the list: http://9fans.net/archive/2003/12/182
Re: [9fans] 8 cores
I'd like to ask a question, but before I do, feel I should say, I've been on this list long enough to understand that Plan 9 is a research vessel, not an OS that's targeted at commercial deployment... That being said, while huge scalability is certainly research-worthy, does anyone actually run anything on Plan 9 that needs or would otherwise benefit from 8+ CPUs and more than a few GB's of RAM? Furthermore, does anyone out there run Plan 9 on non-x86 hardware anymore? winmail.dat
