1. 27 1月, 2022 1 次提交
  2. 21 1月, 2022 1 次提交
    • Z
      feat: 调度相关模块间依赖优化 · 0e3936c4
      zhushengle 提交于
      背景:
          调度、线程、软件定时器、sortlink、percpu、异常、workqueue模块相互耦合,存在很多不属于本模块的实现,
      导致这几个模块间依赖混乱、且到处引用其它模块的内部成员。
      
      方案描述:
          解决上述依赖混乱的问题,为后续调度框架打基础,优化后依赖关系:
      
                                                                    | ---> los_swtmr_pri.h --> workqueue
      los_sortlink_pri.h: ---> los_sched_pri.h --> los_task_pri.h -->
         作为基础算法                                               | ---> ipc
      (现在为双向链表),
      做到功能最小化,
      便于后续其它算法替换
      
      调度框架大体方案描述:
      
      1.cpu run queue ----> 任务延时队列
      
                                               |---- 调度队列
                         |----  EDF        --->
                         |                     |---- 方法(Delay、Suspend、Resume、EntReadyQue、Exit等)
                         |
                         |                     |---- 调度队列
      2.task ---> 调度策略----> SCHED_RR   --->
                         |                     |---- 方法(Delay、Suspend、Resume、EntReadyQue、Exit等)
                         |
                         |                     |---- 调度队列
                         |----> SCHED_IDLE --->
                                               |---- 方法(Delay、Suspend、Resume、EntReadyQue、Exit等)
      
      Close #I4RPRW
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      Change-Id: Ia54dc1b8a4801a225a52e40555490c1dce0bd75e
      0e3936c4
  3. 29 11月, 2021 1 次提交
    • Z
      feat: 支持L1 低功耗框架 · 64e49aba
      zhushengle 提交于
      方案描述:
         和L0保持一致,上层通过proc文件系统操作:
         power_mode  支持的低功耗模式,通过对该文件进行write操作可以设置低功耗模式
         power_count powermanager模块通过对该文件操作,和内核进行交互,简要流程如下:
           while (1) {
             open  // 打开该文件
             read  // 使powermanager低功耗任务常阻塞,当系统无任何模块持锁时,会唤醒该任务
             write // 进行低功耗流程
             close // 关闭该文件
           }
         power_lock    write该文件,持锁
         power_unlock  writw该文件,释放锁
      
      Close #I4JSO
      
      Change-Id: I73fcdeeb5e2039484b3351a81b46a0892b349fe9
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      64e49aba
  4. 02 11月, 2021 1 次提交
  5. 29 10月, 2021 1 次提交
  6. 19 10月, 2021 1 次提交
  7. 28 9月, 2021 1 次提交
    • L
      feat: L0-L1 支持Perf · 6e0a3f10
      LiteOS2021 提交于
          1.【需求描述】:
               L0-L1 支持Perf,提供2种模式的配置, 及3大类型的事件配置:
               2种模式:计数模式(仅统计事件发生次数)、采样模式(收集上下文如任务ID、pc、backtrace等)。
               3种事件类型:CPU硬件事件(cycle、branch、icache、dcache等)、OS软件事件(task switch、mux pend、irq等)、高精度周期事件(cpu          clock)。
          2.【方案描述】:
               L0:
               基于事件采样原理,以性能事件为基础,当事件发生时,相应的事件计数器溢出发生中断,在中断处理函数中记录事件信息,包括当前的pc、当前运         行的任务ID以及调用栈等信息。
               L1:
               新增perf字符设备,位于“dev/perf”,通过对设备节点的read\ioctl,实现用户态perf
      
          BREAKING CHANGE:
          1.新增一系列perf的对外API,位于los_perf.h中.
          LOS_PerfInit配置采样数据缓冲区
          LOS_PerfStart开启Perf采样
          LOS_PerfStop停止Perf采样
          LOS_PerfConfig配置Perf采样事件
          LOS_PerfDataRead读取采样数据
          LOS_PerfNotifyHookReg 注册采样数据缓冲区的钩子函数
          LOS_PerfFlushHookReg 注册缓冲区刷cache的钩子
      
          2. 用户态新增perf命令
        【Usage】:
      ./perf [start] /[start id] Start perf.
      ./perf [stop] Stop perf.
      ./perf [read nBytes] Read nBytes raw data from perf buffer and print out.
      ./perf [list] List events to be used in -e.
      ./perf [stat] or [record] <option> <command>
               -e, event selector. use './perf list' to list available events.
               -p, event period.
               -o, perf data output filename.
               -t, taskId filter(whiltelist), if not set perf will sample all tasks.
               -s, type of data to sample defined in PerfSampleType los_perf.h.
               -P, processId filter(whiltelist), if not set perf will sample all processes.
               -d, whether to prescaler (once every 64 counts), which only take effect on cpu cycle hardware event.
      
          Close #I47I9A
      Signed-off-by: NLiteOS2021 <dinglu@huawei.com>
      Change-Id: Ieb9b7483c85d1495df7c55bc0027f4309dff9814
      6e0a3f10
  8. 31 8月, 2021 1 次提交
    • L
      feat: L0-L1 支持Trace · dc9ec685
      LiteOS2021 提交于
              1.【需求描述】
                  L0~L1 支持Trace,提供两种工作模式:在线模式、离线缓存模式, 用于按时间线追踪系统事件,如任务切换、中断、ipc等。
              2.【方案描述】
                  L0:
                  (1).在内核模块预置静态代码桩
                  (2).触发桩后,收集系统上下文信息
                  (3).离线模式则写入内存,用户可通过dump导出;
                  (4).在线模式通过pipeline对接IDE进行可视化解析和展示;
                  L1:
                  新增trace字符设备,位于"/dev/trace",通过对设备节点的read\write\ioctl,实现用户态trace;
      
              BREAKING CHANGE:
              1.新增一系列trace的对外API,位于los_trace.h中.
              LOS_TRACE_EASY简易插桩
              LOS_TRACE标准插桩
              LOS_TraceInit配置Trace缓冲区的地址和大小
              LOS_TraceStart开启事件记录
              LOS_TraceStop停止事件记录
              LOS_TraceRecordDump输出Trace缓冲区数据
              LOS_TraceRecordGet获取Trace缓冲区的首地址
              LOS_TraceReset清除Trace缓冲区中的事件
              LOS_TraceEventMaskSet设置事件掩码,仅记录某些模块的事件
              LOS_TraceHwiFilterHookReg注册过滤特定中断号事件的钩子函数
      
              Close #I46WA0
      Signed-off-by: NLiteOS2021 <dinglu@huawei.com>
      
      Change-Id: I6a8e64794c4852f2c2980993a06180e09ec6ee0d
      dc9ec685
  9. 07 7月, 2021 1 次提交
  10. 01 7月, 2021 1 次提交
  11. 26 6月, 2021 1 次提交
    • Z
      fix: 修复kill进程时,因liteipc阻塞的进程概率无法退出问题 · 7de43bb0
      zhushengle 提交于
       kill进程时,会将因为liteipc阻塞的线程唤醒,使其调度并自动退出,由于liteipc阻塞机制为
      循环阻塞方式,会导致将因liteipc阻塞的线程唤醒后又进入等待中。此处在唤醒因liteipc阻塞的
      线程后检查是否已有kill标志,如果有使其按接收数据失败退出,在返回用户态之前,该线程会进
      入退出流程,结束运行。
      
      Close #I3XX7K
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      Change-Id: Iec4e298dff4aefd2994289067a35cb5673e323f9
      7de43bb0
  12. 04 6月, 2021 1 次提交
    • Yansira's avatar
      feat: timer_create支持以SIGEV_THREAD方式创建定时器 · e5f6bf05
      Yansira 提交于
      【背景】当前timer_create接口不支持以SIGEV_THREAD的方式创建多个定时器
      
      【修改方案】
      1、内核timer_create接口在创建software timers相应的线程时,使用线程
      taskCB所携带的信息识别各个线程的信号并依据该信息分别派发出信号。
      2、关于用户任务操作许可验证的修改,现在允许同一用户线程向其自身派发信
      号,软件定时器计时结束,向用户态发送相应的信号,完成用户态线程的回调。
      
      【影响】
      对现有的产品暂无影响。
      
      re #I3SRFI
      Signed-off-by: Yansira's avataryansira <yansira@hotmail.com>
      Change-Id: Ia23f5ef01975bf867dd7f5db797a30c264c50501
      e5f6bf05
  13. 24 5月, 2021 1 次提交
    • Z
      fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. · cf89f016
      zhushengle 提交于
      背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
            如果有信号处理就切去处理信号,信号处理结束后回来继续按原来流程执行。
      问题:当用户态线程在执行系统调用或缺页异常时,运行在内核态,如果此时有信
            号需要处理,且该线程已经持有了部分内核资源(如:锁,内存等), 此时如
            果有中断发生,则在中断结束时,就会去处理该信号,此时用户态线程持有
            了内核未释放的资源跑到了用户态去运行,如果该线程在用户态出现问题,
            那么它持有的内核资源就无法被释放了。
      方案:用户态线程在执行系统调用和缺页异常时暂时屏蔽信号,防止此时有中断去
            处理信号,等系统调用结束或缺页异常结束时再去处理信号。
      解决的问题:
        1. 执行系统调用或缺页异常时屏蔽信号,防止中断去处理信号
        2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
        3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程
      
      Close #I3S0N0
      
      Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  14. 20 5月, 2021 1 次提交
  15. 08 5月, 2021 1 次提交
  16. 19 4月, 2021 1 次提交
  17. 11 3月, 2021 1 次提交
  18. 26 12月, 2020 1 次提交
  19. 05 11月, 2020 1 次提交
  20. 13 10月, 2020 1 次提交
  21. 08 9月, 2020 1 次提交