| --- Log opened Sun May 18 00:00:53 2014 | ||
| stekern | blueCmd: while waiting for the "big SMP patch", I give you a couple of minor cleanup/preparation patches: | 07:00 |
|---|---|---|
| stekern | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=66d141a9c964230fd5e07aaa815c3c559056bbd1 | 07:00 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=dffe2d0b4e1993afa8b03a16b83dc3689b9676dd | 07:00 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=ad405ea17b55455bc3f1a4abebd10f3331d9c54c | 07:00 |
| stekern | blueCmd: feeling generous today, and I promised to be transparent: http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=9b26a6592ded949837047558a514166e555dfd1f | 08:27 |
| stekern | still a bit of stubs in there, so it's not quite booting with the second cpu yet | 08:28 |
| stekern | but, I think I've killed most of the bugs in the stuff that *is* implemented... | 08:29 |
| olofk | Does Linux have any regression tests to help implementing stuff like this? | 08:44 |
| olofk | Does it have any tests at all? | 08:44 |
| stekern | if it boots, it works, right? | 08:58 |
| stekern | ;) | 08:58 |
| olofk | If it boots, ship it | 09:01 |
| stekern | I think there are a couple of build-bots that run all sorts of tests and stuff, but not anything "official" like the gcc one I think | 09:02 |
| stekern | besides, I think Linux development model depends on a large amount of users that test, report and/or fix bugs | 09:03 |
| stekern | which of course have it's sides... | 09:03 |
| stekern | -' | 09:03 |
| olofk | Yes. It's probably difficult to do unit testing on the hw-specific drivers | 09:06 |
| olofk | And you won't catch system-level performance regressions with unit test eithers | 09:06 |
| olofk | But maybe file system code and stuff like that could probably benefit from some test cases | 09:07 |
| blueCmd | make randconf! | 09:33 |
| blueCmd | or maybe make randconfig | 09:33 |
| blueCmd | stekern: secondary = "not primary"? | 09:37 |
| blueCmd | i.e. you have one primary core and can have multiple secondary cores | 09:38 |
| stekern | right | 10:05 |
| stekern | !boot_cpu is perhaps the most correct description | 10:05 |
| blueCmd | cool | 10:29 |
| blueCmd | well the code makes sense and AFAICS the logic checks out | 10:29 |
| blueCmd | olofk: so. upstreaming gcc.. | 10:40 |
| stekern | hmm, I'm thinking we should have hw support for the inter-processor interrupts | 14:30 |
| stekern | don't have anything concrete in mind yet, so I just throw it out like that for possible feedback and ideas ;) | 14:31 |
| stekern | one option would of course be a completely generic core that can be written to over the wb bus that generates an irq signal | 14:32 |
| stekern | we already have the interrupt-generator core that we've been using for test purposes | 14:33 |
| stekern | I think it's probably better to make a pure "IPI" core | 18:28 |
| olofk | stekern: Yes. I'm all for a proper Interrupt controller as well | 18:29 |
| olofk | But are there any additional requirements for multicore? | 18:30 |
| stekern | what I'm after now is "sw interrupts, signaled from one core to another/others, with a "message" | 18:31 |
| stekern | " | 18:31 |
| olofk | Like a mailbox? | 18:31 |
| olofk | Well, you need interrupt for that as well of course | 18:32 |
| stekern | so, I'm thinking, each core has its own control reg and its own status reg | 18:32 |
| olofk | For masking and reading and setting level/edge and things like that? | 18:33 |
| stekern | you write cpu # (let's say upper 16-bits) and "message" (let's say lower 16-bits) to the control reg | 18:33 |
| stekern | then irq # goes high to cpu # | 18:34 |
| stekern | and in cpu # status reg is high 16-bit sender cpu, low 16-bit "message" | 18:34 |
| olofk | hmm | 18:36 |
| olofk | If you want messages, my idea is more like: | 18:37 |
| stekern | I think I mixed the upper and lower bits, but you get the point | 18:37 |
| olofk | 1) Sender CPU writes message and destination to mailbox | 18:37 |
| olofk | 2) Receiving CPU gets a mailbox IRQ | 18:37 |
| olofk | 3) Receiveing CPU get the message | 18:37 |
| stekern | how is that different ;) | 18:38 |
| stekern | ? | 18:39 |
| olofk | No limits on message length | 18:39 |
| olofk | mailbox is a separate core from the interrupt controller | 18:39 |
| stekern | ok, I'm not sure I need "messages", more an irq with some data stuck onto it | 18:39 |
| olofk | oh... I see now that our ideas were a bit more similar than I first thought :) | 18:40 |
| olofk | Yes, I don't really understand your use case | 18:40 |
| stekern | ...that of course doesn't mean that the mailbox idea should be dismissed | 18:40 |
| stekern | let me paste a random Linux IPI handler: http://lxr.free-electrons.com/source/arch/alpha/kernel/smp.c#L525 | 18:41 |
| stekern | the things in the "switch (which)" is what I want as "data" attached to the IRQ | 18:41 |
| stekern | it's basically an "irq number container" | 18:43 |
| stekern | so, what I want, is to generate a specific IRQ to another core | 18:44 |
| olofk | ah ok | 18:45 |
| stekern | ...but, then my description of my possible implementation got a bit more generic, since you could basically send "whatever" in that 16-bit container. | 18:46 |
| olofk | If we don't expect too many CPUs, the easiest way would probably be a full IRQ matrix between the CPUs | 18:46 |
| stekern | hmmm... maybe, but I don't see that being much easier than a couple of regs | 18:47 |
| olofk | No, probably not, but I already drifted away a bit here, and came up with a few other features :) | 18:48 |
| stekern | like? ;) | 18:48 |
| olofk | Like how to handle IRQ migration | 18:48 |
| olofk | And isolating CPUs | 18:49 |
| stekern | hmm, yeah, but that's more of a job for a possible "proper Interrupt controller" | 18:50 |
| stekern | (of which the IPI core could be a part of) | 18:50 |
| olofk | When you say registers btw, do you mean SPRs? | 18:55 |
| olofk | Or do you mean a separate core? | 18:55 |
| stekern | no, just WB accessable registers | 18:55 |
| olofk | Would that be handled with a driver and be included in the dts? | 18:56 |
| stekern | yup, something like that | 18:56 |
| olofk | Then we can always switch if we find the time do to a more full blown interrupt controller later on | 18:57 |
| stekern | yeah, I'm trying to make this generic, so the interrupt controller register itself into the generic code as an IPI handler | 18:57 |
| stekern | (that's how arm (and some others) do it) | 18:58 |
| stekern | arm have their gic | 18:58 |
| olofk | Generic Interrupt Controller? | 18:59 |
| stekern | right | 18:59 |
| stekern | to be more precise, here is where the gic register itself to the SMP code as an "IPI handler": http://lxr.free-electrons.com/source/drivers/irqchip/irq-gic.c#L962 | 19:00 |
| stekern | so the "IPI core" driver would basically just do that | 19:01 |
| stekern | something like this: http://pastebin.com/egseE4wY | 20:04 |
| stekern | ...completely untested | 20:05 |
| olofk | ahh.. I didn't know you could define several localparam at once | 20:07 |
| olofk | But it's the same way for regs and wires, so why not | 20:08 |
| stekern | mmm, I don't like wires and regs defined like that though ;) | 20:12 |
| olofk | It might be an idea to inhibit writes if there is already a pending irq | 20:12 |
| olofk | haha. Me neither, but it looked good for localparams in this case | 20:13 |
| stekern | yes, I think it's good for grouping them together. Makes enum-like params almost look like enums. | 20:13 |
| stekern | (inhibit writes) hmm... perhaps.. we could also add a "IRQ pending" bit to the status reg, and it can be handled in sw | 20:15 |
| stekern | I think the "IRQ pending" bit in the status reg is a good idea either way | 20:16 |
| olofk | Not sure I have thought this through, but I'm worried that you may get zombie irqs if you write to the control register multiple times with different dest cores | 20:18 |
| stekern | not sure what a zombie irq is, but if you do that, you'll fire off multiple irqs to multiple cores | 20:19 |
| stekern | each dest core has it own status reg | 20:19 |
| olofk | I just made up zombie irq because I couldn't come up with a better name :) | 20:21 |
| olofk | ok, looking a bit more, the problem is rather that another core can overwrite the pending irq | 20:22 |
| stekern | yes, a "mailbox fifo" would of course remove that problem | 20:23 |
| stekern | ...but then the core is suddenly a lot more complicated | 20:23 |
| olofk | Agree, but couldn't you just stall the write until the IRQ is cleared | 20:24 |
| stekern | so, I've added a "IRQ pending" bit to the status reg, that is directly connected to the irq output | 20:24 |
| olofk | Or raise the rty line, if anyone listens to that :) | 20:24 |
| stekern | that way, a irq generating cpu can first check the dest cpu's status reg for old pending IRQs before issuing a new | 20:25 |
| olofk | So it's up th sw to poll the status reg first. That works just as fine | 20:25 |
| stekern | I think that's better, then the generating cpu at least have a chance to do something else useful while it's waiting for the dest cpu to handle old irqs | 20:26 |
| olofk | Ahh that's true. Delaying the ack in this case is just mean | 20:27 |
| stekern | ...instead of waiting for a stalled wb bus | 20:27 |
| olofk | And we are nice people | 20:27 |
| stekern | we are... or at least we try to make people believe that ;) | 20:27 |
| olofk | Why don't you add an IRQ instead of polling? ;) | 20:27 |
| stekern | haha | 20:27 |
| stekern | it'll be in the "fancy, can do it all controller" | 20:28 |
| olofk | Yep. The Turing complete IRQ controller with a built-in Forth interpreter | 20:28 |
| stekern | in that, you'll be able to reroute the negated irq to yourself | 20:28 |
| olofk | I'm going to write the first interrupt controller with an app store | 20:29 |
| blueCmd | olofk: haha | 21:13 |
| -!- Netsplit *.net <-> *.split quits: poke53281, fotis2, pgavin, Findeton, blueCmd, olofk, imphil, mdeininger, ams, phoohb, (+20 more, use /NETSPLIT to show all of them) | 22:14 | |
| -!- Netsplit over, joins: Findeton, knz, O01eg, pgavin, skip_, blueCmd, ssvb, wallento, zama, fotis2 (+20 more) | 22:20 | |
| --- Log closed Mon May 19 00:00:55 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!