----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/#review9066 -----------------------------------------------------------
I think the commit message could be a bit clearer about the problem this patch is attempting to solve. The key issue seems to be that you might be trying to simulate multiple threads on a single host thread. Therefore you can't implement blocking system calls that rely on signaling from other threads by spinning/blocking in the syscall code. So this patch forces the system call to bump down the event queue every X cycles so that other simulated threads can make forward progress. - Michael LeBeane On Nov. 7, 2016, 11:20 p.m., Brandon Potter wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3680/ > ----------------------------------------------------------- > > (Updated Nov. 7, 2016, 11:20 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11702:149a5af69d1a > --------------------------- > syscall_emul: [patch 13/22] add system call retry capability > > This changeset adds functionality that allows system calls to retry without > affecting system state during on system call returns. > > We need this functionality to solve problems with blocking system calls > in multi-process or multi-threaded simulations where information is passed > between processes/threads. > > For example, consider two processes that are producer/consumer. They can > use file descriptors and read/write to pass the information between one > another. However if the consumer calls the blocking read system call before > the producer has produced anything, the call will block the event queue and > deadlock the simulation. The trick it to recognize that the system calls will > block and then reschedule at some later point when the call would succeed > without blocking. In subsequent patches, we recognize that a syscall will' > block by calling a non-blocking poll and check for events. > > > Diffs > ----- > > src/sim/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/syscall_desc.hh PRE-CREATION > src/sim/syscall_desc.cc PRE-CREATION > src/cpu/checker/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/checker/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/minor/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/commit.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/commit_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/cpu.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/cpu.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/dyn_inst.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/dyn_inst_impl.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/o3/thread_state.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/atomic.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/exec_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple/timing.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/simple_thread.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/thread_context.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/sim/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/pseudo_inst.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/BaseCPU.py 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/base.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/cpu/base.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/arm/faults.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/mips/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/power/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/sparc/linux/process.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/sparc/linux/process.cc 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/isa/decoder/one_byte_opcodes.isa > 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/x86/isa/decoder/two_byte_opcodes.isa > 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/alpha/isa/decoder.isa 4a86763c0b30cccba0f56c7f48637a46a4663b06 > src/arch/arm/faults.hh 4a86763c0b30cccba0f56c7f48637a46a4663b06 > > 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