| --- Log opened Tue Jul 23 00:00:39 2013 | ||
| poke53281 | olofk: Patches send to the mailing list. Let's see | 03:16 |
|---|---|---|
| stekern | poke53281: how did you generate those patches? | 06:48 |
| stekern | it looks like git format-patch, but with the e-mail information stripped, so it doesn't apply with git am | 06:50 |
| poke53281 | well, the email was wrong, so I removed this part. I thought the interesting part is below "---" | 06:53 |
| poke53281 | Sorry | 06:54 |
| poke53281 | no problem to send the patches again ... tomorrow. | 06:55 |
| stekern | yeah, np, I can apply them for testing as is, the commit info get lost though | 06:56 |
| stekern | but that's not so important, jeremybennett is the one that should commit them | 06:57 |
| poke53281 | just changing the email address in the document seems not problem. I think the first line includes a sha1 hash | 07:04 |
| poke53281 | ....seems to be a problem ... | 07:05 |
| stekern | 'git send-email' works pretty well too | 07:09 |
| stekern | but that would of course not have fixed your first problem, that the e-mail was wrong | 07:11 |
| jeremybennett | poke53281: Thanks for your patch. I've asked for a couple of extra things, then it can be committed to both branches | 08:25 |
| -!- Netsplit *.net <-> *.split quits: enghong, jakob_ | 10:59 | |
| -!- Netsplit over, joins: enghong | 10:59 | |
| stekern | woot! | 15:09 |
| * stekern got to Linux prompt with hw itlb reload | 15:10 | |
| stekern | in the verilated model at least | 15:10 |
| stekern | simple stuff like 'cat /proc/cpuinfo', 'top', 'ls' and 'uname -a' works too at least | 15:11 |
| stekern | coremark too | 15:41 |
| stekern | this seems stable enough, let's move onto dtlb reloading | 15:41 |
| stekern | that should be a walk in the park, no annoying fetch corner cases to give you headaches | 15:43 |
| juliusb | !! | 16:26 |
| juliusb | awesome stuff | 16:27 |
| juliusb | how much faster do you estimate this is stekern? | 16:27 |
| poke53281 | stekern: Perfect | 16:36 |
| poke53281 | Did someone test the eglibc port so far. I have realized that it moved to the official github.com/openrisc site | 16:40 |
| stekern | juliusb: extremely rough estimate, from just comparing the time a random software dtlb exceptions take and a random hardware itlb reload in the waveforms I get 1500ns/200ns | 16:40 |
| juliusb | ... you mean 1500ns down to 200ns? | 16:43 |
| stekern | yeah, 1500 vs 200 for the two cases | 16:45 |
| juliusb | oh nice | 16:45 |
| juliusb | we usually simulate at 50MHz (20ns clock period), so about 75cycles versus 10? | 16:46 |
| juliusb | that's a real performance win :) | 16:46 |
| stekern | and with the stats from poke53281s jor1k, we saw that dtlb misses can go up to about 25% (do I remember correct?) during a 'gcc hello_world.c' | 16:46 |
| olofk | Farewell sweet uptime | 16:46 |
| stekern | I mean, 25% of the time spent on handling dtlb misses | 16:47 |
| stekern | poke53281: I think only blueCmd (who's done the work on it) have tested it, afaik it's not complete, but somewhat working | 16:50 |
| juliusb | oh jebus! | 16:52 |
| juliusb | that's a high proportion of time spent doing that | 16:52 |
| stekern | I just forked it over to the openrisc site to show that there exist an effort of a eglibc port =P | 16:52 |
| stekern | jebus, the prophet of openrisc? | 16:53 |
| juliusb | Maybe that's Lampret | 16:54 |
| poke53281 | stekern: Yes, you are right. The dtlb misses took a lot of performance. 25% at least | 16:55 |
| juliusb | he came, gave us the word of open source CPU development, and has then gone | 16:55 |
| juliusb | and we hold out hope for his return | 16:55 |
| juliusb | haha | 16:55 |
| juliusb | (well, not actually) | 16:56 |
| stekern | amen | 16:56 |
| juliusb | oh yeah btw I'm going to talk at OHS 2013 in Boston this year | 17:04 |
| juliusb | I'm getting 6 minutes | 17:04 |
| juliusb | :) | 17:04 |
| poke53281 | 6 minutes sound more like Hello and Good bye. I guess 1 minute is for questions. :) | 17:08 |
| stekern | well, think about it this way, most internet meme videos on youtube are less than 6 minutes, you can make an impression in that time at least =P | 17:15 |
| poke53281 | There is a very annoying bug in the kernel which I think started around 3.9. There is a unaligned access in this loop: http://git.openrisc.net/cgit.cgi/jonas/linux/tree/drivers/tty/vt/keyboard.c#n1509 | 17:59 |
| poke53281 | The kbd_struct uses a lot of bit variables. http://git.openrisc.net/cgit.cgi/jonas/linux/tree/include/linux/kbd_kern.h#n24 | 18:01 |
| poke53281 | So I am not sure, either change the gcc compiler or patch the Linux kernel or include a proper unaligned access handler in the kernel. | 18:06 |
| poke53281 | Indeed that is the only unaligned access I could find. All other user-space progs I have compiled sp far don't use unaligned accesses. | 18:07 |
| stekern | ah, I think I've seen that too, but iirc in 3.8 already | 18:14 |
| stekern | I had to disable the ps/2 interface on my atlys board, to be able to continue with what I was doing right then | 18:16 |
| stekern | without looking closer though, sounds odd that bitfields in chars would generate unaligned accesses | 18:18 |
| stekern | but I think our struct padding in gcc is buggy, so could be related to that | 18:18 |
| poke53281 | in the evening I will take a closer look and program a small test program. | 18:19 |
| stekern | doing sizeof(struct eth_hdr) does not return 14 for instance | 18:19 |
| stekern | and I *think* one of the testsuite fails is related to that | 18:19 |
| stekern | the first fail, that is | 18:19 |
| poke53281 | bitfields should be always be padded to word alignment I think | 18:19 |
| stekern | hmm, yeah, that might be. That would be a problem then, since the struct starts with 2 chars | 18:21 |
| stekern | have to take a look in the standard | 18:21 |
| stekern | ...but right now it's time for bed | 18:22 |
| poke53281 | good night | 18:22 |
| olofk | It's insane that there are only five minute slots at OHS. | 21:34 |
| poke53281 | How many talks are there in howmany days?. And how many people are visiting this place? | 22:16 |
| --- Log closed Wed Jul 24 00:00:40 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!