IRC logs for #openrisc Thursday, 2014-06-12

--- Log opened Thu Jun 12 00:00:30 2014
olofkCrap! I Alt-F4'd my simulation07:25
olofkOh well. At least it came far enough to start NFS07:26
olofkNot sure I need NFS in Icarus. Should probably make some changes to that kernel07:26
olofkAre there any plans to do something about arch/openrisc/kernel/ in the kernel? Do any other arches have the same issue?07:33
olofkAhh.. I see that other arches have ifdef's controlled by a CONFIG_. Should we do something similar? Either a or1k/or32 checkbox, a list of valid names or free text07:55
olofka list would perhaps make the most sense if we want to have or1k, or1knd and or32, and perhaps some future sub arch or 64-bit versions07:56
olofkPlease note that I don't really have a fucking clue about these things, so comments are appreciated :)07:57
LoneTecholofk: I'm not even sure what issue you refer to08:43
stekernolofk: yes, we should do something about it08:50
olofkLoneTech: We can't link the kernel with the or1k- toolchain10:55
olofkHmm... so far in the boot I have executed ~38M instructions, and spent 10% of them inside of memset12:43
olofkSo optimizing that to write words instead should increase the performance ~7.5% (not sure on the math here)12:44
olofkWhat the hell... there's even a nop in there12:45
olofkIn the inner loop12:45
olofkAre the memset routines from the kernel or from gcc or newlib?12:46
LoneTechI would have guessed gcc, as I don't recall the kernel ever using anything of newlib12:47
_franck__look at stekern answer12:57
_franck__olofk: this is for you ^12:57
_franck__I started something but I switched to something else. I compiled musl memcpy, disassembled it and started to optimize it in order to put the result in the kernel12:59
olofkYeah, I remember that we have talked about it before13:10
stekern~70 patches left in my rebase experiment...13:12
olofkThe current one doesn't seem very complicated though. Just shuffling around a few instructions to remove the nop would make it ~20% faster (stalls not taken into consideration)13:13
olofkLooks like my simulation stopped now13:17
olofkPoor Icarus13:17
olofkOh well. It got through almost ~39M instructions at least13:18
olofkStole the memset from microblaze instead. Let's see how that turns out :)13:56
olofkstekern: Exactly what are you doing? Do we have 400 patches in the OpenRISC tree that haven't made it upstream?14:02
stekernolofk: 74014:17
stekernbut at least ~670 of those have made it to upstream, but in another form than they were committed14:19
ysionneauwhat are you going to do? create a new branch from top of upstream and rebase the not yet upstreamed patches onto it?14:21
stekernthat's what I've done, yes14:25
ysionneauthen you will say "please don't develop anymore on the old dev branch but on the new one rebased upon upstream" ?14:26
* ysionneau is curious about the workflow14:26
stekernno, this is just my own tree, I'm just doing it because I wanted to get an overview of the differences14:27
stekerneveryone should develop against upstream anyway14:28
ysionneauand it's just you in your local development cycle who diverged from upstream?14:28
stekernwhat jonas will do with his tree, that's up to him14:28
stekernno, there's all kind of stuff there14:29
ysionneauI mean, do you have an "official" repo for the openrisc community with the openrisc kernel?14:29
stekernold and 'new'14:29
ysionneauwhich you from time to time rebase on Linus' tree14:29
stekernjonas send pull-request to Linus from his repo at git.openrisc.net14:30
stekern...but it's another branch than the master branch14:31
ysionneauso basically everyone commit in master branch in git.openrisc.net14:31
ysionneauthen jonas keeps some other branch up to date to send to Linus14:32
ysionneaulike "for-linus"14:32
ysionneauah there is stefan/linux and jonas/linux14:33
stekernyes ;)14:54
_franck__"everyone should develop against upstream anyway"   ---> totally agree14:56
stekern...but currently there are a bunch of patches scattered around that you need14:58
_franck__that too bad14:58
_franck__and that shouldn't be the case14:59
stekernI think there are only two that _really_ matters14:59
_franck__so they _really_ should be pushed15:00
stekernand the other jonas posted to lkml in 2011, but got no response15:00
_franck__so we have an unmaintained upstream kernel. stekern you should volunteer to be an openrisc kernel co-maintainer15:29
-!- Netsplit *.net <-> *.split quits: zama19:02
-!- Netsplit over, joins: zama19:03
stekerntry that and see if you have the same problem as you had with vanilla upstream20:02
-!- Netsplit *.net <-> *.split quits: Amadiro20:18
-!- Netsplit over, joins: Amadiro20:18
--- Log closed Fri Jun 13 00:00:32 2014

Generated by 2.15.2 by Marius Gedminas - find it at!