Re: [9fans] 8 cores
Uriel wrote: 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... Hmmm... I would doubt it until tried... I could imagine that databases use mmap() havily and the mmap() of linuxemu is just a hack that that reads the whole file-mapping in... and writes the whole thing out again on msync()... thats one reason the startup time of firefox is so slow on linuxemu (besides it makes millions of stats/open/access calls when starting up) if Firefox runs, anything can! I have seen so mutch programs breaking in obscure ways while hacking linuxemu... sure, sometimes you are lucky and it just works... but still dont expect too mutch... uriel cinap
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] Plan 9 on MacBook?
> I now have a more-or-less unused MacBook. I'm
> considering spending some time trying to get Plan 9
> working on it. Has anyone gotten beyond confirming
> that it won't work out of the box?
I have Plan 9 booting on an Intel Macbook. When I was
first testing it out, there were problems with the
SATA driver but Erik fixed those and it works fine
now. The only change that you'll have to make is in
the keyboard initialization for both the kernel and
9load.
Add the following at the beginning of these functions:
/sys/src/9/pc/kbd.c:/^kbdinit
/sys/src/boot/pc/kbd.c:/^i8042init
+c = inb(Status);
+if(c & Rtimeout){
+print("no keyboard present\n");
+return;
+}
Oh, and you're going to need to supply a plan9.ini
with sufficient parameters since you don't have
keyboard input until you can run usb/kb.
If I get some time on Saturday, I'll post a write-
up on how to bootstrap the system using a spare
partition on the Mac.
Also, I started an ethernet driver for the Yukon 2
chip that's in the Macbook. I had to put it aside
for a while but I'm slowly getting back into it.
Anthony
[9fans] acme g/$/ funny
Edit ,x/.*/g/$/a/foo/ shouldn't this append "foo" after every line? sam gives slightly different behaviour here (but still questionable) - it appends "foo" after every empty line. is this actually a bug, or have i misunderstood the way that '$' is meant to work? it does seem strange that in the following edit command, the guard never matches anything. Edit ,x/foo$/g/foo$/d
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] Plan 9 on MacBook?
> I have Plan 9 booting on an Intel Macbook. Is this likely to work on macbook pro as well, or is the architecture too different?
[9fans] sources.cs.bell-labs.com
appears not to be in dns. did i miss a change? - erik
Re: [9fans] Plan 9 and multicores/parallelism/concurrency?
On Mon, 2008-07-14 at 18:12 -0400, [EMAIL PROTECTED] wrote: > // Not just inexpensive, but also better aligned with how > // they use compute resources (virtual vs. physical threads) > // and memory resources. > > Hrm. I know about the memory/cache issues, but it sounds > like there's more on the CPU side I don't know much about. > Is there more here beyond the memory question and > prediction/pipelining? With, what is called CMT, we now have the following hierarchy of compute resources: -> physical CPU -> cores -> virtual threads and the following set (I can't quite call it a hierarchy) of memory resources: physical RAM attached to a particular CPU's memory controller L3/L2 cache L1 cache These two set of resources can be "attached" to each other in a number of different ways (e.g. L1 could be the only per-core cache or L2 could also be per-core, etc.) and the job of a scheduler is to figure out the best mapping of tasks to compute resources based on alignment constraints. Paul had a nice post on these constraints earlier. Here's an old post from Ingo outlining what is NOT free with HyperThreading: http://lwn.net/Articles/8553/ > // Speaking of which -- is SPARC port of Plan9 still alive? > > Not really. There's a partially-working sparc64 port out there > which ran on the Ultra 1 (I think), but it's neither been kept up > to date nor made to run on anything beyond that. A few folks > (including myself) have poked at it a bit with varying results, > none of which were particularly good. > > Something on Batoka would provide better motivation than my > old Ultra 5, though! I don't think I can help much with that, but if I ever see a homeless Batoka in the hallway it'll be FedExed to you in no time ;-) Thanks, Roman.
Re: [9fans] acme g/$/ funny
>Edit ,x/.*/g/$/a/foo/ >shouldn't this append "foo" after every line? Edit ,x/.*\n/g/\n/a/foo or Edit ,x/.*\n/g/$/a/foo where the latter gives a little hint about what the code might be doing
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), > > 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. 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 - erik
Re: [9fans] Plan 9 and multicores/parallelism/concurrency?
> These two set of resources can be "attached" to each other in a number > of different ways (e.g. L1 could be the only per-core cache or L2 > could also be per-core, etc.) and the job of a scheduler is to figure > out the best mapping of tasks to compute resources based on > alignment constraints. Paul had a nice post on these constraints > earlier. Here's an old post from Ingo outlining what is NOT free > with HyperThreading: >http://lwn.net/Articles/8553/ in my performace testing, try and theorize as i might, i have not yet been able to see l2 or other cache effects on intel machines. i may have seen l1 cache effects, but i rather think the reason that pinning the process to a cpu helped was that it was being scheduled when it wasn't needed on the other cpu. (that is, the design was wrong anway.) what i have seen is that the intel 82598 10gbit chip, by keeping its tx and rx descriptor rings in cachable regular memory can mash the fsb to little bits. it's still pretty fast, though. there's no use going fast, if you have no data to go fast on. - erik
Re: [9fans] 8 cores
On Thu, Jul 17, 2008 at 2:07 AM, 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 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). mmap can also reduce memory pressure, since there's only one copy of the data (for some kernels anyway; others are smarter). In a number of kernels, the read path for page-aligned page-sized data is via mmap anyway, so any measurement at that point is going to make mmap look cheaper. Even the read path is an mmap! Looking at the Plan 9 exec path it's hard to see a reason that Plan 9 could not do mmap, it just doesn't. But lots of code nowadays depends on mmap being there. Is there something I'm missing? ron
Re: [9fans] sources.cs.bell-labs.com
On Thu, Jul 17, 2008 at 4:57 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: > appears not to be in dns. did i miss a change? nope, hang in there. It's not you. ron
Re: [9fans] Plan 9 and multicores/parallelism/concurrency?
On Thu, Jul 17, 2008 at 5:40 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: > what i have seen is that the intel 82598 10gbit chip, by keeping > its tx and rx descriptor rings in cachable regular memory can > mash the fsb to little bits. it's still pretty fast, though. > it's funny how often this lesson is relearned. But cost is the driver, and memory-free NICS are cheaper ... there are even memory-free infiniband cards now. But I remember a A Quadrics guy telling me he never wanted to put descriptors into main memory ever, ever again. ron
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] acme g/$/ funny
On Jul 17, 2008, at 6:03 AM, roger peppe wrote: Edit ,x/.*/g/$/a/foo/ shouldn't this append "foo" after every line? sam gives slightly different behaviour here (but still questionable) - it appends "foo" after every empty line. is this actually a bug, or have i misunderstood the way that '$' is meant to work? it does seem strange that in the following edit command, the guard never matches anything. Edit ,x/foo$/g/foo$/d You misunderstood how Pike regexps work, and it's a bug in sam. The pattern /./ matches everything EXCEPT a newline, which would be matched with $. The guard, then, should never work, as the following proves: ,x/.*/g/$/p As expected, no output (for sam too). So acme is acting correctly. Why sam does something, then, with a// is beyond me (a long undiscovered bug, perhaps?). The following worked for me for both sam and acme: ,x/$/a/foo/ On Jul 17, 2008, at 8:44 AM, Charles Forsyth wrote: Edit ,x/.*\n/g/\n/a/foo That appends foo at the beginning of the next line. Try i/foo/.
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] acme g/$/ funny
On Thu, Jul 17, 2008 at 2:07 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote: > ,x/$/a/foo/ i was actually trying to do something slightly different; my original command was: ,x/^[ \t]*let.*/v/in$/a/ in/ and i worked around it by doing ,x/^[ \t]let.*\n/v/in\n/x/\n/i/ in/ which wasn't too bad. i just wondered if the behaviour i saw was actually a bug, as $ matches the null string at the end of a line, and i was matching against the null string at the end of a line. i think i understand why it doesn't work; but should it work differently?
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
> 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" :-) on plan 9? where? - erik
Re: [9fans] 8 cores
Paweł Lasek wrote: 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. you can write you own allocator with brk() or segattach()/segbrk()/segfree() too... the only things you cant is: - map on some fixed address - remap cinap
Re: [9fans] 8 cores
On Thu, Jul 17, 2008 at 6:46 AM, erik quanstrom <[EMAIL PROTECTED]> wrote: >> 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" :-) > > on plan 9? where? I can't remember ... ron
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, 2008-07-17 at 05:55 -0700, ron minnich wrote: > Looking at the Plan 9 exec path it's hard to see a reason that Plan 9 > could not do mmap, it just doesn't. But lots of code nowadays depends > on mmap being there. Is there something I'm missing? I've commented privately to Erik that this is, in fact, what I'm interested in: using mmap() not as a first-class abstraction, but as a useful optimization technique in places where it can speed things up. Thanks, Roman. P.S. Of course, as was pointed out (a) speeding things up in one place (read/write) could easily slow them down elsewhere in the kernel (b) there's no point in lots of RPMs if 99% you're in neutral and (a) is precisely why I tend to ask question instead of implementing this stuff up -- I'm just not all that much of an OS kernel guy to be 100% sure that it will end up being worth it.
[9fans] mmap
Mmap means many things to many people. Using mmap is most often not a matter of performance as much as it is a matter of flexibility: being able to mmap files is about as close as most operating systems get to exposing the underlying page table hardware, which lets applications that aren't happy with the OS-provided interface essentially design their own. The canonical example is databases, which would really prefer to be operating systems except for the whole having to write hardware drivers thing. 9vx is another example. If all you want is to map a few read-only (or at least non-write-back) files, like you'd need to implement dynamically-loaded shared libraries, that's not too hard to add. Back when I did the first cut of linuxemu, I changed segattach to accept 'file!a.out' as a segment name. If you've got a lot of these, you might need to change the segment array to be larger or perhaps dynamically sized. The particular interface I chose felt clumsy so I never even suggested putting it into the kernel, but mostly you can reuse the code that demand-loads ordinary Plan 9 binaries. The shared-library kind of mmap is by far the simplest mmap use case. Even allowing mmap as a surrogate for malloc would probably push you pretty far toward needing to rewrite the memory system, since the mmap-based mallocs tend to use a large number of small mappings. True mmap support in the Plan 9 kernel would require rewriting the entire memory system to work in terms of pages instead of the coarser regions the kernel calls segments (text, data, bss, stack). This would be a lot of work with almost zero benefit. I'd rather let those applications not happy with what Plan 9 provides just not use Plan 9. There's no need to be all things to all people. Also, on Plan 9, shared memory means that the memory at the time of rfork is shared. If one proc then does a segattach, the other proc sharing its memory will not see the segattach. The same is true of segdetach. This is another reason that you can't just reuse the existing mechanisms to hack in a traditional full-featured mmap. To really get those right you might need (gasp) TLB shootdowns, which would be even more work. It's nice that Plan 9's memory system is simple--just a few segments, each of which is a run of pages. "True" mmap support would destroy that. Please don't. Russ
Re: [9fans] mmap
> in a traditional full-featured mmap i've noticed that some combinations of words are scarier than others. ☺ - erik
Re: [9fans] acme g/$/ funny
> On Jul 17, 2008, at 6:03 AM, roger peppe wrote: >> Edit ,x/.*/g/$/a/foo/ >> >> shouldn't this append "foo" after every line? >> >> sam gives slightly different behaviour here >> (but still questionable) - it appends "foo" after >> every empty line. >> >> is this actually a bug, or have i misunderstood the >> way that '$' is meant to work? >> >> it does seem strange that in the following edit >> command, the guard never matches anything. >> >> Edit ,x/foo$/g/foo$/d >> pietro: > You misunderstood how Pike regexps work > ... > That appends foo at the beginning of the next line. Try i/foo/. It always brings a smile to my face when you say things like that to people who have forgotten more about Plan 9 than you know. Thank you. rog: > Edit ,x/.*/g/$/a/foo/ > > shouldn't this append "foo" after every line? I would have expected it to. pietro: > The pattern /./ matches everything EXCEPT a newline, > which would be matched with $. This is only half right. $ matches the empty string before a newline, not the newline itself. Don't believe me? Search for $$. The real issue here is that inside an x/.*/ loop, the text being considered has no newline, so the position at the end is no longer an "empty string before a newline." (The newline is outside the search window.) One possible fix would be to redefine $ to match the end of the text as well as before newlines. I've sometimes wanted that in x loops that don't iterate over whole lines. That would have the unfortunate effect that if you had a four-line file like: abc\n def\n ghi\n jkl\n and you ran ,s/$/!/g you would then have the four-and-a-half line file: abc!\n def!\n ghi!\n jkl!\n ! so you'd have to then define that $ matches the end of the text unless the last character is a newline. This is the point where I usually give up and decide the current semantics are not worth fiddling with. Russ
[9fans] low-cost pcie serial card found
serial is getting pretty hard to use. lots of low-end motherboards otherwise perfect for plan 9, either don't have serial ports or have the irq mappings screwed up in the mp table. i'm batting 1.000 at home with terminal/ cpu server mb with screwed-up serial. all the machines i want to have serial consoles have two serial ports that work great. :-\ also, many of the cards supported by plan 9 are very expensive if you don't need 32 serial ports in a system and they don't support pcie. after a crash that scrolled right off the cga, i finally broke down and took a chance on the StarTech 4 port pci-e 16c950 card. (p/n pex4s950) from newegg http://www.newegg.com/Product/Product.aspx?Item=N82E16815158087&Tpk=startech%2bpex4s950 complete with octopus cable for $100. other than the fact that the cable and card need to be mashed together with excessive force, it works great. (i did need to remove the card from the case to apply enough pressure to make them.) the crystal speed is 1843200hz. patch uartpex4s950 is on sources. - erik
Re: [9fans] Corrupted meta data
> Can you clri the file from fossilcons? Unfortunately, that just reports the corrupted meta data too. Interestingly, when I started it up this morning, the check didn't report an error with it. But then after trying to access it, check now reports: error: could not unpack meta block: /active/sys/src/9/pc[3]: corrupted meta data What does the 3 refer to? The 3rd block of the pc directory, maybe? The pc directory itself seems fine. I can see everything else there. main.8 doesn't show up in an lc. If my current directory is elsewhere and I try to ls -l /n/fossil/sys/src/9/pc/main.8, it comes up as not existing. But if my current directory is /n/fossil/sys/src/9/pc, then I get the corrupted meta data error. I haven't changed anything in that directory, so in principle, I guess i could blow away the directory (clri if necessary) and copy it all back from a venti snapshot. But before I do that, I'd like to see if a more direct recovery is possible. BTW, I had it lock up again this morning. I've noticed that when it does, it uses 100% of the CPU. It's acting like it's stuck in a spin lock. I can't say for sure, so this may be a red herring, but it has seemed that every time it's locked up, it's been when doing I/O to the sdloop device. Thanks, BLS
Re: [9fans] Plan 9 on MacBook?
On Thu, Jul 17, 2008 at 2:32 AM, Anthony Martin <[EMAIL PROTECTED]> wrote:
> > I now have a more-or-less unused MacBook. I'm
> > considering spending some time trying to get Plan 9
> > working on it. Has anyone gotten beyond confirming
> > that it won't work out of the box?
>
> I have Plan 9 booting on an Intel Macbook. When I was
> first testing it out, there were problems with the
> SATA driver but Erik fixed those and it works fine
> now. The only change that you'll have to make is in
> the keyboard initialization for both the kernel and
> 9load.
>
Using boot camp I presume? So you have a BIOS. That or someone did EFI
support under the radar (which might still be cool even though it sucks).
>
> Add the following at the beginning of these functions:
>/sys/src/9/pc/kbd.c:/^kbdinit
>/sys/src/boot/pc/kbd.c:/^i8042init
>
> +c = inb(Status);
> +if(c & Rtimeout){
> +print("no keyboard present\n");
> +return;
> +}
>
> Oh, and you're going to need to supply a plan9.ini
> with sufficient parameters since you don't have
> keyboard input until you can run usb/kb.
>
> If I get some time on Saturday, I'll post a write-
> up on how to bootstrap the system using a spare
> partition on the Mac.
>
> Also, I started an ethernet driver for the Yukon 2
> chip that's in the Macbook. I had to put it aside
> for a while but I'm slowly getting back into it.
>
> Anthony
>
>
Re: [9fans] Corrupted meta data
> error: could not unpack meta block: /active/sys/src/9/pc[3]: corrupted meta > data > What does the 3 refer to? The 3rd block of the pc directory, > maybe? Yes. Your best bet is probably to clri /active/sys/src/9/pc and not look back. > BTW, I had it lock up again this morning. I've noticed that > when it does, it uses 100% of the CPU. It's acting like > it's stuck in a spin lock. I can't say for sure, so this > may be a red herring, but it has seemed that every time > it's locked up, it's been when doing I/O to the sdloop > device. Locks on Plan 9 don't use 100% of the cpu. Even spin locks start sleeping after enough contention. It's more likely in a bad loop somewhere. Is it repeatedly doing I/O during the 100% cpu? Russ
Re: [9fans] Corrupted meta data
> Your best bet is probably to clri /active/sys/src/9/pc > and not look back. clri /active/sys/src/9/pc no_lb_mode = 1 ; It is happy now. > It's more likely in a bad loop somewhere. > Is it repeatedly doing I/O during the 100% cpu? I don't honestly know. Next time it happens, I'll check and see. BLS
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] Corrupted meta data
> It's more likely in a bad loop somewhere. > Is it repeatedly doing I/O during the 100% cpu? It just locked again. Here's what I'm seeing. In top, the first thread is using 100% of the CPU and all the other threads are in the S state with no run time. I don't see any indications either in vmstat or in load from p9p that there is any I/O going on to speak of or an unusual number of system calls being issued. If there's anything else I can check, let me know. Thanks, BLS
Re: [9fans] setting up a differnet keyboard
Pietro Gagliardi wrote: 9fat: cp /sys/lib/kbmap/uk /n/9fat try again with kbmap=uk and reboot. Yes, I tried that but it didn't work either. This probably because it's boot not 9load that's running at this point.. Francisco J Ballesteros wrote: I think you need to add the map to the kernel, as a root file so that boot could find it before reaching the file server. In which case, this doesn't seem to be a very practical mechanism. Wouldn't it be beter to attach to the server and then do the kbmap() stuff ?? A related question: cp /sys/lib/kbmap/uk /dev/kbmap in my lib/profile changes the keyboard, but when put it into /bin/termrc (at the end) it doesn't do anything. Can anyone tell me why Many thanks Bob
Re: [9fans] setting up a differnet keyboard
>> I think you need to add the map to the kernel, as a root file so that >> boot could find it before reaching the file server. >> > > In which case, this doesn't seem to be a very practical mechanism. Wouldn't > it be beter to attach to the server and then do the kbmap() stuff ?? not when you need to type your password at the console and that password contains non-ascii characters. I believe this is the original reason kbmap() was added in the boot code (by Francisco Ballesteros, if my memory is correct).
Re: [9fans] setting up a differnet keyboard
> In which case, this doesn't seem to be a very practical mechanism. > Wouldn't it be beter to attach to the server and then do the kbmap() > stuff ?? that's a good chicken-and-egg question. at the stage of boot where kbmap is run, factotum has not been run and there is no fileserver. the advantage to doing the mapping here is that passwords can be entered normally. the disadvantage is that you can't get the file from the fileserver --- you can't authenticate to it. if you wait until you have auth set up, you could use files from the fs, but you'd have one convention for entering passwords and another for entering everything else. (assuming all the chars in your password are typable with your keyboard and the standard layout interpretation.) so the only solution is to build the kbmap into the kernel. i'm not going to try this, so i might mess a few details up, but this is close to what you want to do. 1. use "kbmap=/boot/uk" 2. edit your terminal configuration. generally this is /sys/src/9/pc/pc. in the bootdir section add "/sys/lib/kbmap/uk" 3. make your kernel "mk 'CONF=pc' install" 4. copy /386/9pc to wherever you boot from. if you're changing the name of your kernel, then be sure to edit your plan9.ini, too. 5. reboot. after booting, you can verify that you've got it right by mount /srv/boot /n/boot lc /boot you should see a file named "uk" in /boot. (and your keyboard should work correctly.) - erik
Re: [9fans] Plan 9 and multicores/parallelism/concurrency?
On Tue, 15 Jul 2008 10:50:46 PDT Paul Lalonde <[EMAIL PROTECTED]> wrote: > > On 15-Jul-08, at 1:01 AM, Bakul Shah wrote: > > > > I suspect a lot of this complexity will end up being dropped > > when you don't have to worry about efficiently using the last > > N% of cpu cycles. > > Would that I weren't working on a multi-core graphics part... That N% > is what the game is all about. I was really wondering about what might happen when there are 100s of cores per die. My reasoning was that more and more cores can be (and will be) put on a die but a corresponding increase in off chip memory bandwidth will not be possible so at some point memory bottleneck will prevent 100% use of cores even if you assume ideal placement of threads and no thread movement to a different core. > > When your bottleneck is memory bandwidth > > using core 100% is not going to happen in general. > > But in most cases, that memory movement has to share the bus with > increasingly remote cache accesses, which in turn take bandwidth. > Affinity is a serious win for reducing on-chip bandwidth usage in > cache-coherent many-core systems. I was certainly not suggesting moving threads around. I was speculating that as the number of cores goes up perhaps the kernel is not the right place to do affinity scheduling or much any sophisticated scheduling. > > And I am > > not sure thread placement belongs in the kernel. Why not let > > an application manage its allocation of h/w thread x cycle > > resources? I am not even sure a full kernel belongs on every > > core. > > I'm still looking for the right scheduler, in kernel or user space, > that lets me deal with affinitizing 3 resources that run at different > granularities: per-core cache, hardware-thread-to-core, and cross-chip > caches. There's a rough hierarchy implied by these three resources, > and perfect scheduling might be possible in a purely cooperative > world, but reality imposes pre-emption and resource virtualization. Some friends of mine are able to sqeeze a lot of parallelism out supposedly hard to parallelize code. But this is in a purely cooperative worlds where they assume threads don't move and where machines are dedicated to specific tasks. > > Unlike you I think the kernel should do even less as more and > > more cores are added. It should basically stay out of the > > way. Less government, more privatization :-) So may be > > the plan9 kernel would a better starting point than a Unix > > kernel. > > Agreed, less and less in the kernel, but *enough*. I like resource > virtualization, and as long as it gets affinity right, I win.
[9fans] good fun
I know a lot of folks on this list like history, so check this one out: http://www.fas.org/sgp/othergov/doe/lanl/docs1/LA-6943-H.pdf " Further- more, by using clip leads to short one side of the vacuum-tube flipflops, you could actually change the contents of a register (while the machine was stopped). A skilled operator, like Don Bradford or Verna Ellingson Gardiner, could fetch a word into a register, make a change in it using clip leads, and store it back in memory in about the same time that most modern operators can type a one-line com- mand on a terminal. " enjoy. ron
Re: [9fans] setting up a differnet keyboard
andrey mirtchovski wrote: not when you need to type your password at the console and that password contains non-ascii characters. I believe this is the original reason kbmap() was added in the boot code (by Francisco Ballesteros, if my memory is correct). Ahh yes..Good point. I confess to having a shamelessly terminal-centric view of Plan9 at the moment... Bob
Re: [9fans] setting up a differnet keyboard
Many thanks for this recipe. For the moment, though, I am going to stick with my cp /sys/lib/kbmap/uk /dev/kbmap in my profile Unless there is a good reason why I shouldn't? Bob erik quanstrom wrote: In which case, this doesn't seem to be a very practical mechanism. Wouldn't it be beter to attach to the server and then do the kbmap() stuff ?? that's a good chicken-and-egg question. at the stage of boot where kbmap is run, factotum has not been run and there is no fileserver. the advantage to doing the mapping here is that passwords can be entered normally. the disadvantage is that you can't get the file from the fileserver --- you can't authenticate to it. if you wait until you have auth set up, you could use files from the fs, but you'd have one convention for entering passwords and another for entering everything else. (assuming all the chars in your password are typable with your keyboard and the standard layout interpretation.) so the only solution is to build the kbmap into the kernel. i'm not going to try this, so i might mess a few details up, but this is close to what you want to do. 1. use "kbmap=/boot/uk" 2. edit your terminal configuration. generally this is /sys/src/9/pc/pc. in the bootdir section add "/sys/lib/kbmap/uk" 3. make your kernel "mk 'CONF=pc' install" 4. copy /386/9pc to wherever you boot from. if you're changing the name of your kernel, then be sure to edit your plan9.ini, too. 5. reboot. after booting, you can verify that you've got it right by mount /srv/boot /n/boot lc /boot you should see a file named "uk" in /boot. (and your keyboard should work correctly.) - erik
Re: [9fans] setting up a differnet keyboard
> Many thanks for this recipe. > For the moment, though, I am going to stick with my > cp /sys/lib/kbmap/uk /dev/kbmap in my profile > > Unless there is a good reason why I shouldn't? as long as you're happy with it, and don't mind the gotcha, i don't see that it would be a problem. but there are 7 characters i know aren't in your password. and if i got out a uk keyboard, i'd know 7 more. :-) i do add some characters to my keyboard map with my profile, but these are for convience, not to fix broken mappings. i map the otherwise-unused f keys to some common unicode unicode characters. - erik
[9fans] sam question
related to the earlier discussion, for stripping the \r at the end of lines in windows files, i use: ,x/$/ c// where is a cut&pasted return char (yes, i could use '.' instead, but i'm paranoid.) x doesn't seem to recognize \r as a escape sequence. true?
Re: [9fans] sam question
> related to the earlier discussion, for stripping the \r at the end of
> lines in windows files, i use:
>
> ,x/$/ c//
>
> where is a cut&pasted return char (yes, i could use '.' instead,
> but i'm paranoid.) x doesn't seem to recognize \r as a escape
> sequence. true?
no they don't: sam/regexp.c and acme/regx.c both have a lex function
that starts basically like this (from acme)
int
lex(void){
int c;
c = *exprp++;
switch(c){
case '\\':
if(*exprp)
if((c= *exprp++)=='n')
c='\n';
i suppose you could also type 000d.
- erik
Re: [9fans] sam question
On Jul 17, 2008, at 8:28 PM, erik quanstrom wrote: i suppose you could also type ctl+m
Re: [9fans] Plan 9 and multicores/parallelism/concurrency?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 17, 2008, at 12:29 PM, Bakul Shah wrote: My reasoning was that more and more cores can be (and will be) put on a die but a corresponding increase in off chip memory bandwidth will not be possible so at some point memory bottleneck will prevent 100% use of cores even if you assume ideal placement of threads and no thread movement to a different core. As the number of cores increases you have to hugely increase the amount of cache - you need cache enough for a large enough working set to keep a core busy during the long wait for its next slice of bandwidth (figurative slice - the multiplexing clearly should finer grained). Latency hiding on those fetches is critically important. I was certainly not suggesting moving threads around. I was speculating that as the number of cores goes up perhaps the kernel is not the right place to do affinity scheduling or much any sophisticated scheduling. Largely agreed. The real tension is in virtualizing the resources, which beats against affinity. Affinity is clearly an early loser in oversubscribed situations, but it would be a major win to have a scheduler (in or out of kernel) that could degrade intelligently in the face of oversubscription, instead of the hard wall you get when you throw away affinity. Some friends of mine are able to sqeeze a lot of parallelism out supposedly hard to parallelize code. But this is in a purely cooperative worlds where they assume threads don't move and where machines are dedicated to specific tasks. Envy. The other part not to forget about is data-parallel. At least in graphics we get to recast most of our heavy loads to data-parallel, which has huge benefits. If you can manage data-parallel with a nice task DAG and decent load-balancing you can do wonders at keeping data on-chip while pushing lots of flops. Paul, patiently awaiting hardware announcements so he can talk freely. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFIgA6hpJeHo/Fbu1wRAvZUAJ0WxfsfPHZJSclLwhgLj8ibkdgDiwCgx80y 7WT72MW7TsELUwi7jSATr/8= =5nHw -END PGP SIGNATURE-
