IRC logs for #openrisc Thursday, 2013-12-05

--- Log opened Thu Dec 05 00:00:54 2013
hansfbaierstekern: looks interesting04:28
ysionneaucan do synthesis with iverilog/yosys and Python (Migen framework)10:04
stekernysionneau: nice10:10
stekernI saw the ML post about yosys being able to do lm32, that's cool10:10
stekernmakes me want to test it on mor1kx as well10:10
ysionneauhehe :)10:11
ysionneauyosys is still pretty young it had some issues with generate statements and localparams etc10:11
ysionneaubut it seems promising!10:11
stekernsure does10:11
stekernthe author seemed pretty responsive as well (that's my deduction from the ML post)10:12
stekern(to clarify, I'm speaking about the milkymist/m-labs mailing list)10:13
ysionneauyes so I bet that if you find issues when synthetizing mork1x, he would fix them right away :)10:14
ysionneaudoes mork1x mmu support address space ids?10:15
stekernno, but the or1k architecture does10:15
stekernLinux doesn't make use of them though10:16
ysionneauso you flush tlb at context switch?10:16
ysionneauah? I didn't know Linux had a poor support of asid10:16
ysionneauNetBSD uses them10:16
stekernI mean't the or1k port of Linux doesn't make use of them10:17
stekernthat's arch specific stuff10:17
ysionneauah ok so it's a choice of the port maintainer10:17
stekerniirc ARM use the ASID stuff that they have in linux10:17
ysionneauso what do you do? an ASID for kernel and one for user space?10:18
ysionneauor just one asid and total flush10:18
stekernI'm not sure, haven't looked very closely at what arm does in that regard10:20
ysionneaui'm trying to add asid to lm32 mmu, but I don't have a clear mind about how it's implemented in other archs10:21
stekernbut aren't the asid just used to map PIDs into them?10:22
ysionneauespecially what happens uppon exception (does the hardware need to switch the current asid?) and uppon return from exception (eret) (does the hardware need to switch back current asid to what it was before?)10:22
ysionneauwell PIDs or another algorithm yes10:22
ysionneauyou ASID are limited by the number of bits you have for them, so you wanna make sure you attribute ASID to the mostly used PIDs10:23
ysionneauand to those who do inter process stuff a lot10:23
ysionneauand to unassign an ASID from a sleepy PID10:23
stekernhmm, yes... but can you (easily) do tricky stuff like that?10:24
stekernI think I will read up a bit on this stuff in the evening, it's interesting10:25
ysionneauwell you can try, I mean you have to allocate anyway ASID to PIDs even if they don't take so much cpu time ("nice" too high etc, not real time)10:26
ysionneaubecause you want them to run anyway10:26
ysionneaubut you can at least try to evict from the tlb the ASID associated to the less important PID10:26
ysionneaunot the one waking up very often, doing a lot of job etc10:26
ysionneauand for instance you never want to evict asid 0 which is usually the kernel10:27
stekernok, yes, but isn't that unrelated to the ASID? you want to evict the less important TLB (which probably boils down to the same thing)10:28
ysionneauah yes, you're right, asid and tlbe are unrelated10:29
ysionneauyou could associate an asid to a PID10:29
ysionneauwhich has no entry at all in the TLB10:29
ysionneaubut you want to minimize those cases10:29
ysionneauyou want to allow a maximum of PID to share the TLB10:30
ysionneaubut in the end, if your tlb is too small, you may end up with the tlb being full with only one ASID10:30
ysionneauwhich defeats the goal of ASIDs :/10:31
ysionneausorry I think I'm not explaining it very well :)10:34
stekernno, I think it's a perfectly fine explanation10:35
stekernI understand what you are saying ;)10:35
--- Log closed Fri Dec 06 00:00:56 2013

Generated by 2.15.2 by Marius Gedminas - find it at!