--- Log opened Wed Jul 10 00:00:20 2013 | ||
stekern | poke53282: Or we have more bugs to catch ;) | 01:52 |
---|---|---|
stekern | one thing out of the way (for the moment at least): http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00400.html | 01:53 |
stekern | now we can just hope they accept it | 01:54 |
poke53281 | Great | 02:32 |
stekern | poke53281: just remembered a thing I was supposed to ask you, IIRC you implemented some kind of hardware tlb refill in jor1k | 02:44 |
stekern | did you patch the kernel to use IMMUCR to get the page table base pointer, or how do you do that? | 02:45 |
poke53281 | No, in principle I wrote the Exception_Handler in Javascript. Have to know the pointer to the Linux pagetable. | 02:49 |
poke53281 | So I rewrote the the assembler to Javascript. | 02:51 |
poke53281 | But I am not sure if this really speeds up everything. It happens not so often as expected. | 02:51 |
stekern | I'm asking, because on my list of things to do, I'm planning on adding hw pagetable walk in mor1kx | 02:53 |
stekern | patching the kernel to put the pagetable base pointer into I/DMMUCR is not a big problem, I'm just thinking if there are other (SW) obstacles | 02:55 |
poke53281 | CPU.prototype.AnalyzeImage = function() // get addresses for fast refill | 02:56 |
poke53281 | { | 02:56 |
poke53281 | this.boot_dtlb_misshandler_address = this.ram.int32mem[0x900 >> 2]; | 02:56 |
poke53281 | this.boot_itlb_misshandler_address = this.ram.int32mem[0xA00 >> 2]; | 02:56 |
poke53281 | this.current_pgd = ((this.ram.int32mem[0x2018>>2]&0xFFF)<<16) | (this.ram.int32mem[0x201C>>2] & 0xFFFF); | 02:56 |
poke53281 | } | 02:56 |
poke53281 | Terrible solution as it depends on the specific kernel. | 02:56 |
poke53281 | As far as I know there are no problems. | 02:58 |
poke53281 | Have to restart my system. One moment | 02:58 |
stekern | Ah, I see. Otoh, those addresses rarely change, so you're pretty safe across kernel versions ;) | 03:08 |
stekern | should be pretty straight forward then to do the hw tlb refill in mor1kx I think | 03:15 |
poke53281 | Oh man, getting crazy here. I want to download a file from my web server. 512kb. Tried every browser I have (3). Everyone saves the wrong file size. wget does it right. Restarted everything. The same. | 03:19 |
stekern | interesting note about tlb misses not being significant, but perhaps you just haven't been memory hungry enough for it to notice? | 03:20 |
poke53281 | could be. I have a counter in simulationcorner.net/opencore4/ | 03:20 |
poke53281 | It is a slow version of the official version | 03:20 |
stekern | ah, nice, I've been thinking about adding something like that to the verilated model (or or1ksim) | 03:21 |
stekern | now I can just use yours ;) | 03:22 |
poke53281 | mount /dev/sda /mnt | 03:22 |
poke53281 | you can find more | 03:23 |
poke53281 | more software | 03:23 |
stekern | I see you've also noticed the odd tick timer behaviour in or1ksim, where the timer is stopped when the spr is written with continous mode and the match reg matches | 03:23 |
stekern | I'm thinking we should change or1ksim in that regard, none of the "hard" implementation I know of behaves like that, and it's against the spec | 03:24 |
poke53281 | Agree | 03:27 |
stekern | running gcc hello.c, there is approx. 1000 - 3000 itlb misses/s and 10 000 - 30 000 dtlb misses/s | 03:34 |
stekern | (I'm assuming that the stats are updated 1 time/s?) | 03:35 |
poke53281 | yes, but they are not resetted | 03:35 |
stekern | yeah, I get that, I just roughly looked at how much they increased at each update | 03:36 |
poke53281 | And in this emulator you have around works at around 6MIPS. | 03:36 |
poke53281 | In Hardware every miss takes I don't know around 100-200Instructions? | 03:37 |
poke53281 | that would mean that he spends 30% of his time in the miss handlers | 03:38 |
stekern | depending on how fast your machine is, I get around 4MIPS here | 03:38 |
poke53281 | If you try the official version you can get up to 20-30MIPS with Firefox. | 03:38 |
poke53281 | Ok, 100 instructions is maybe too much for the miss handler, but 50 should be Ok | 03:39 |
poke53281 | I use the same size as or1ksim for the tlb | 03:42 |
stekern | yup, ~50 seems about right | 03:43 |
stekern | so about 25% when taking my MIPS number into the equation | 03:47 |
poke53281 | Yes, so this is really a lot. Is there another architecture with a software miss handler? | 03:49 |
poke53281 | I found it fascinating. | 03:49 |
stekern | MIPS I believe | 03:49 |
stekern | sparc? | 03:49 |
stekern | but it's this kind of numbers I need to motivate to do the hw implementation ;) | 03:50 |
stekern | +me | 03:50 |
poke53281 | So, ho much do you think you can reduce it by a hardware implementation? | 03:50 |
stekern | when idling there's only about 30 itlb misses/s and 100 dtlb misses/s | 03:51 |
poke53281 | well we can try to increase the tlb first. | 03:53 |
stekern | not sure, I guess the mem access is the one that is going to take most time, but you kind of have that problem in the sw implementation too | 03:53 |
poke53281 | yes | 03:54 |
poke53281 | This is the main reason why the ips fluctuates by +-2MIPS | 03:54 |
stekern | interesting, I get those ata read errors on this laptop too, if you remember | 04:11 |
stekern | on my home machine it doesn't happen | 04:11 |
poke53281 | What do you do. At the moment there is a bug hd0088 I try to fix. Some problem with apache | 04:13 |
poke53281 | startx does not work because of this | 04:13 |
poke53281 | And a problem are of course timeouts. And I am restarting the httpd server at the moment several times | 04:13 |
stekern | running gcc hello.c | 04:14 |
stekern | (restarting httpd) aha, yeah, that might explain it ;) | 04:14 |
poke53281 | What is written in the console? | 04:14 |
poke53281 | It shows you which part of the hd it is downloading at the moment | 04:15 |
stekern | now it worked on the laptop too | 04:15 |
poke53281 | can you give me the file size you downloaded from opencore4/hd/hd0088? Should be 512 kb | 04:16 |
poke53281 | compare between browser and wget. | 04:16 |
stekern | it's 578 619 bytes | 04:18 |
stekern | wget gives 524 288 bytes | 04:19 |
poke53281 | Yes, crazy. I think it has something to do with the gzip compression of this file. I am trying to disable it. But I don't find the correct config. | 04:20 |
stekern | heh, yeah, that sounds crazy | 04:25 |
poke53281 | http://www.gidnetwork.com/tools/gzip-test.php | 04:26 |
poke53281 | If you test this file it gives you an error. All other files are Ok | 04:26 |
stekern | hexdumping the browser downloaded shows ".fcp" as the first thing in the file | 04:31 |
stekern | then there's some font related strings further down | 04:32 |
stekern | googling .fcp you get hits about Final Cut Pro (some video formats) | 04:33 |
stekern | could it be that the file somehow get's confused with a video file, or is that just grasping at straws | 04:34 |
poke53281 | Yes, you are right. It thinks that this is a video Content-Type video/unknown. | 04:39 |
poke53281 | Yeah, this is the plug-in mod-mime magic which makes a file inspection | 04:45 |
poke53281 | Nope, X is still unstable | 06:01 |
stekern | syncing gcc against the 4.8.1 release was fairly painless | 09:53 |
stekern | I've only built it so far though | 09:53 |
-!- Netsplit *.net <-> *.split quits: forkG_ | 09:57 | |
-!- Netsplit *.net <-> *.split quits: LoneTech, Guest45696 | 13:29 | |
-!- trevorman is now known as Guest96468 | 13:31 | |
-!- Netsplit *.net <-> *.split quits: poke53281, trevorman_, Amadiro | 13:57 | |
-!- Netsplit *.net <-> *.split quits: poke53282, hle_ | 14:17 | |
-!- trevorma- is now known as trevorman | 14:18 | |
-!- trevorman is now known as Guest46407 | 15:04 | |
-!- Netsplit *.net <-> *.split quits: Amadiro | 15:32 | |
-!- Netsplit *.net <-> *.split quits: jonibo | 20:53 | |
-!- Netsplit *.net <-> *.split quits: poke53282, jeremybennett | 21:17 | |
--- Log closed Thu Jul 11 00:00:21 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!