utterances-bot commented 2 years ago

练习参考答案 - rCore-Tutorial-Book-v3 3.6.0-alpha.1 文档

https://rcore-os.github.io/rCore-Tutorial-Book-v3/chapter3/6answer.html

kkocdko commented 2 years ago

编程题 3. 编写浮点应用程序A

请问什么是“浮点应用程序”呢？是类似 ./user/src/bin/01power_5.rs 这样，然后随意计算一个浮点运算任务么？

TD-Sky commented 1 year ago

unsafe fn __switch(current_task_cx_ptr: *mut TaskContext, next_task_cx_ptr: *const TaskContext) {
    SWITCH_TIME_START = get_time_us();
    switch::__switch(current_task_cx_ptr, next_task_cx_ptr);
    SWITCH_TIME_COUNT += get_time_us() - SWITCH_TIME_START;
}

编程题4的此处，为什么__switch跳完栈切换完指令后，仍能完成增加计时的运算？

kayoch1n commented 1 year ago

2.4 第三点的描述感觉不对

通过时钟中断切换任务： ... 切换到新任务后，在 trap 结尾处遇到函数 user_time_start()，刷新停表，并统计新任务的内核态时间

按照 ch3 的实现，__switch 函数通过直接恢复ra来切到新任务，不会返回到trap的结尾

wyfcyx commented 1 year ago

@kayoch1n 没问题呀，假设是两个任务轮流执行的情况，一个任务时间片用尽进入trap，调用suspend_current_and_run_next，最终调用__switch切换到另一个任务。另一个任务时间片也用尽，通过__switch切换回来的时候，要切换回的ra其实是调用__switch的指令的下一条指令，所以会从__switch返回的地方继续执行，最后走到trap结尾。再看看__switch对ra的处理吧。

kayoch1n commented 1 year ago

@kayoch1n 没问题呀，假设是两个任务轮流执行的情况，一个任务时间片用尽进入trap，调用suspend_current_and_run_next，最终调用__switch切换到另一个任务。另一个任务时间片也用尽，通过__switch切换回来的时候，要切换回的ra其实是调用__switch的指令的下一条指令，所以会从__switch返回的地方继续执行，最后走到trap结尾。再看看__switch对ra的处理吧。

ok了，我的代码有点问题，修改之后是可以返回并且走到trap结尾的

kayoch1n commented 1 year ago

关于第三个问题支持浮点运算，我觉得可以提一下需要事先将 sstatus.fs 设置为一个非0的值，否则尽管编译target包含了浮点指令拓展、程序首次执行浮点指令的时候会抛出illegal instruction异常。

这里3.1.6.6有提到这个点，而且我自己在qemu上试了一下确实会直接抛出异常，设置成1之后可解决这个首次执行异常的问题

When an extension’s status is set to Off, any instruction that attempts to read or write the corresponding state will cause an illegal instruction exception.

HangX-Ma commented 1 year ago

unsafe fn __switch(current_task_cx_ptr: *mut TaskContext, next_task_cx_ptr: *const TaskContext) {
    SWITCH_TIME_START = get_time_us();
    switch::__switch(current_task_cx_ptr, next_task_cx_ptr);
    SWITCH_TIME_COUNT += get_time_us() - SWITCH_TIME_START;
}

编程题4的此处，为什么__switch跳完栈切换完指令后，仍能完成增加计时的运算？

他这里的答案有问题，__switch 之后会跳转到 __restore 恢复到用户态，后面那句只有下一次用户态 trap 后才会执行。 ~~虽然不对我还是测试了一下，发现 context switch 要花费几百毫秒，这肯定是不可能的。~~ 可行的办法是在 goto_restore 中更改入口地址：

这里我的测试可能是出了问题，见后续评论与Mars的讨论。

pub fn goto_restore(kstack_ptr: usize) -> Self {
    extern "C" {
        fn __pre_restore();
    }
    Self {
        ra: __pre_restore as usize,
        sp: kstack_ptr,
        s: [0; 12],
    }
}

之后在 trap.S 末尾加上

__pre_restore:
    mv a0, sp
    call switch_cost
    mv sp, a0
    j __restore

计时的函数是

// os/src/task/mod.rs
pub static mut SWITCH_TASK_START: usize = 0;

pub unsafe fn __switch(current_task_cx_ptr: *mut TaskContext, next_task_cx_ptr: *const TaskContext) {
    SWITCH_TASK_START = get_time_us();
    switch::__switch(current_task_cx_ptr, next_task_cx_ptr);

crate::task::update_switch_cost(get_time_us() - SWITCH_TASK_START); 
}
...
pub fn update_switch_cost(cost: usize) {
    let mut inner = TASK_MANAGER.inner.exclusive_access();
    let current = inner.current_task;
    inner.tasks[current].switch_time += cost;
}

// os/src/trap/mod.rs
#[no_mangle]
pub unsafe extern "C" fn switch_cost (cx: &mut TrapContext) -> &mut TrapContext {
    crate::task::update_switch_cost(get_time_us() - SWITCH_TASK_START); 
    cx
}

TaskControlBlock 中要增加 pub switch_time: usize。