pussuw commented on PR #15820: URL: https://github.com/apache/nuttx/pull/15820#issuecomment-2655874391
> Thank you @pussuw, some questions below :-) > > * Is it safe to enable this irq on all harts? Can you provide a reference to specification or advise that this is common practice? Yes, PLIC will handle arbitration between cores. Only a single core will ever handle an interrupt request from a single source. https://five-embeddev.com/riscv-priv-isa-manual/Priv-v1.12/plic.html > * Would you advise this update also on other RISC-V cores or is it MPFS specific? If people want to port this code to their platforms, by all means. I will not do such a thing since I cannot test them. > * What happens when hart gets the irq that it knows nothing about? Will it discard, redirect, crash? I mean if a task runs on a specific hart how other harts will know who should handle the irq? The PLIC arbitration will handle the decision which hart gets to run the interrupt. In this sense, all harts are equal and it does not make a difference from the application's point of view which hart handles the interrupt. All harts know how to handle any interrupt. For AMP configurations, we obviously do not enable interrupts for harts that do not belong to NuttX, if this is what you mean ? Only cores allocated to NuttX are enabled here. > * You mention single irq execution, but what happens when there are many frequent irq to handle, wouldn't it flood all harts with unrelated irq? No, only a single hart will ever run a single interrupt request from an interrupting source. When the interrupt handler is being executed, the same interrupt source will not interrupt another hart, if this is what you mean ? > * Do you have some sort of improvement metrics for single irq handling and irq flood? I did not do any measurements of this, but as I said, there is no irq flood. > * Can you please provide runtime test logs of `apps/ostest` with SMP enabled and disabled? I don't have ostest enabled on my MPFS hardware. I don't use any upstream'd boards myself. I also believe this is out of scope of this PR, since ostest does not really use interrupts (besides serial and timer, perhaps). > * I don't have this board, so cannot verify locally, does anyone else have this board and can verify? :-) The board I use is our own product, so don't worry, no one else has it either :) Closest thing in upstream would be icicle board I guess, but that does not provide a lot of interrupt sources, so the testing is very shallow, much like with ostest. Only the serial connection and timer are running. Regarding why I did not test with ostest (when touching common risc-v code I always do btw): The testing is done on our own product, which has many digital buses with multiple sensors and outputs (I2C,SPI,CAN,Serial,PWM etc) and a TON of interrupts running concurrently. The test I ran is far more comprehensive from interrupt handling point of view compared to ostest. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
