----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/#review9442 -----------------------------------------------------------
Ship it! Ship It! - Michael LeBeane On Feb. 17, 2017, 10:03 p.m., Brandon Potter wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3680/ > ----------------------------------------------------------- > > (Updated Feb. 17, 2017, 10:03 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11859:2f88471df39a > --------------------------- > syscall_emul: [patch 13/22] add system call retry capability > > This changeset adds functionality that allows system calls to retry without > affecting thread context state such as the program counter or register values > for the associated thread context (when system calls return with a retry > fault). > > This functionality is needed to solve problems with blocking system calls > in multi-process or multi-threaded simulations where information is passed > between processes/threads. Blocking system calls can cause deadlock because > the simulator itself is single threaded. There is only a single thread > servicing the event queue which can cause deadlock if the thread hits a > blocking system call instruction. > > To illustrate the problem, consider two processes using the producer/consumer > sharing model. The processes can use file descriptors and the read and write > calls to pass information to one another. If the consumer calls the blocking > read system call before the producer has produced anything, the call will > block the event queue (while executing the system call instruction) and > deadlock the simulation. > > The solution implemented in this changeset is to recognize that the system > calls will block and then generate a special retry fault. The fault will > be sent back up through the function call chain until it is exposed to the > cpu model's pipeline where the fault becomes visible. The fault will trigger > the cpu model to replay the instruction at a future tick where the call has > a chance to succeed without actually going into a blocking state. > > In subsequent patches, we recognize that a syscall will block by calling a > non-blocking poll (from inside the system call implementation) and checking > for events. When events show up during the poll, it signifies that the call > would not have blocked and the syscall is allowed to proceed (calling an > underlying host system call if necessary). If no events are returned from the > poll, we generate the fault and try the instruction for the thread context > at a distant tick. Note that retrying every tick is not efficient. > > As an aside, the simulator has some multi-threading support for the event > queue, but it is not used by default and needs work. Even if the event queue > was completely multi-threaded, meaning that there is a hardware thread on > the host servicing a single simulator thread contexts with a 1:1 mapping > between them, it's still possible to run into deadlock due to the event queue > barriers on quantum boundaries. The solution of replaying at a later tick > is the simplest solution and solves the problem generally. > > > Diffs > ----- > > src/arch/alpha/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/arm/faults.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/arm/faults.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/mips/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/power/isa/decoder.isa f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/riscv/faults.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/sparc/linux/process.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/sparc/linux/process.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/isa/decoder/one_byte_opcodes.isa > f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/isa/decoder/two_byte_opcodes.isa > f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/process.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/process.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/arch/x86/pseudo_inst.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/BaseCPU.py f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/base.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/base.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/checker/cpu.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/checker/thread_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/exec_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/minor/exec_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/commit.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/commit_impl.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/cpu.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/cpu.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/dyn_inst.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/dyn_inst_impl.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/thread_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/o3/thread_state.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/simple/atomic.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/simple/exec_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/simple/timing.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/simple_thread.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/cpu/thread_context.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/sim/faults.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/sim/faults.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/sim/process.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/sim/process.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/sim/syscall_desc.hh f438fcbab00edbb36075e1403da75cb9a9ac7f55 > src/sim/syscall_desc.cc f438fcbab00edbb36075e1403da75cb9a9ac7f55 > > Diff: http://reviews.gem5.org/r/3680/diff/ > > > Testing > ------- > > > Thanks, > > Brandon Potter > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
