Record all memory allocation and release, save to ram, used to analyze memory allocation rate and memory usage
Its absolute value is not trustworthy because the memory will be allocated in thread A and released in thread B
netinit-5 [0] 0.105984392: tracing_mark_write: C|5|Heap Usage|96|free: heap: 0x606000000020 size:24, address: 0x603000000370
netinit-5 [0] 0.105996874: tracing_mark_write: C|5|Heap Usage|24|free: heap: 0x606000000020 size:72, address: 0x6070000008e0
nsh_main-4 [0] 3.825169408: tracing_mark_write: C|4|Heap Usage|2177665|free: heap: 0x606000000020 size:424, address: 0x614000000840
nsh_main-4 [0] 3.825228525: tracing_mark_write: C|4|Heap Usage|14977|free: heap: 0x606000000020 size:2162688, address: 0x7f80a639f800
nsh_main-4 [0] 3.825298789: tracing_mark_write: C|4|Heap Usage|15189|malloc: heap: 0x606000000020 size:20, address: 0x6030000003a0
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
Signed-off-by: Neo Xu <neo.xu1990@gmail.com>
To align with the implementation of ARMv7-A, remove the operation of clearing
interrupts during GIC initialization to avoid losing interrupts during asynchronous startup.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
This PR support Nested interrupt in armv6/7/8m:
There are two types of nested interrupt model:
Zero latency nested interrupt
Interrupt Priority Note
Data abort Highest
SVC 0x50
High irq1 0x60 ISR can't access system API
irq_save() 0x70
High irq2 0x80 ISR can't access system API
normal irq3 0xB0
We have already support this mode before this PR
Nested interrupt which interrupt level lower than up_irq_save()
Interrupt Priority Note
Data abort Highest
SVC 0x70
irq_save() 0x80
High irq1 0x90 ISR can access system API
High irq2 0xA0 ISR can access system API
normal irq3 0xB0
Now, this PR can support this mode
Signed-off-by: ligd <liguiding1@xiaomi.com>
reason:
In the kernel, we are planning to remove all occurrences of up_cpu_pause as one of the steps to
simplify the implementation of critical sections. The goal is to enable spin_lock_irqsave to encapsulate critical sections,
thereby facilitating the replacement of critical sections(big lock) with smaller spin_lock_irqsave(small lock)
Signed-off-by: hujun5 <hujun5@xiaomi.com>
reason:
To remove the "sync pause" and decouple the critical section from the dependency on enabling interrupts,
after that we need to further implement "schedlock + spinlock".
changelist
1 Modify the implementation of critical sections to no longer involve enabling interrupts or handling synchronous pause events.
2 GIC_SMP_CPUCALL attach to pause handler to remove arch interface up_cpu_paused_restore up_cpu_paused_save
3 Completely remove up_cpu_pause, up_cpu_resume, up_cpu_paused, and up_cpu_pausereq
4 change up_cpu_pause_async to up_send_cpu_sgi
Signed-off-by: hujun5 <hujun5@xiaomi.com>
reason:
In x86_64, g_current_regs is still used for context switching.
This commit fixes the regression from https://github.com/apache/nuttx/pull/13616
Signed-off-by: hujun5 <hujun5@xiaomi.com>
signal handler stack must be properly aligned, otherwise vector instructions doesn't work in signal handler
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
move initial RSP for AP cores below regs area.
otherwise IDLE thread for AP cores can be corrupted
XCP region now match regs allocation in up_initial_state()
Signed-off-by: p-szafonimateusz <p-szafonimateusz@xiaomi.com>
As the handling of sp_el0 was moved from the context switch routine
to exception entry/exit, we must set sp_el0 explicitly when the user
process is first started.
Summary
The original implement for exception handler is very simple and
haven't framework for breakpoint/watchpoint routine or brk instruction.
I refine the fatal handler and add framework for debug handler to
register or unregister. this is a prepare for watchpoint/breakpoint
implement
Signed-off-by: qinwei1 <qinwei1@xiaomi.com>
reason:
by doing this we can reduce context switch time,
When we exit from an interrupt handler, we directly use tcb->xcp.regs
before
text data bss dec hex filename
178368 876 130604 309848 4ba58 nuttx
after
text data bss dec hex filename
178120 876 130212 309208 4b7d8 nuttx
szie change -248
Signed-off-by: hujun5 <hujun5@xiaomi.com>
for the citimon stats:
thread 0: thread 1:
enter_critical (t0)
up_switch_context
note suspend thread0 (t1)
thread running
IRQ happen, in ISR:
post thread0
up_switch_context
note resume thread0 (t2)
ISR continue f1
ISR continue f2
...
ISR continue fn
leave_critical (t3)
You will see, the thread 0, critical_section time is:
(t1 - t0) + (t3 - t2)
BUT, this result contains f1 f2 .. fn time spent, it is wrong
to tell user thead0 hold the critical lots of time but actually
not belong to it.
Resolve:
change the nxsched_suspend/resume_scheduler to real hanppends
Signed-off-by: ligd <liguiding1@xiaomi.com>
Register: smp
Register: nsh
Register: sh
Register: getprime
Register: ostest
Espressif HAL for 3rd Party Platforms: b4c723a119344b4b71d69819019d55637fb570fd
common/xtensa_cpupause.c: In function 'xtensa_pause_handler':
common/xtensa_cpupause.c:240:3: warning: implicit declaration of function 'xtensa_savestate'; did you mean 'xtensa_setps'? [-Wimplicit-function-declaration]
240 | xtensa_savestate(tcb->xcp.regs);
| ^~~~~~~~~~~~~~~~
| xtensa_setps
common/xtensa_cpupause.c:243:3: warning: implicit declaration of function 'xtensa_restorestate'; did you mean 'xtensa_context_restore'? [-Wimplicit-function-declaration]
243 | xtensa_restorestate(tcb->xcp.regs);
| ^~~~~~~~~~~~~~~~~~~
| xtensa_context_restore
Signed-off-by: hujun5 <hujun5@xiaomi.com>
/vela/nuttx/drivers/pci/pci_ecam.c:432:(.text.pci_ecam_get_irq+0x16): undefined reference to `up_get_legacy_irq'
Signed-off-by: Yongrong Wang <wangyongrong@xiaomi.com>
reason:
Currently, if we need to schedule a task to another CPU, we have to completely halt the other CPU,
manipulate the scheduling linked list, and then resume the operation of that CPU. This process is both time-consuming and unnecessary.
During this process, both the current CPU and the target CPU are inevitably subjected to busyloop.
The improved strategy is to simply send a cross-core interrupt to the target CPU.
The current CPU continues to run while the target CPU responds to the interrupt, eliminating the certainty of a busyloop occurring.
Signed-off-by: hujun5 <hujun5@xiaomi.com>
