----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3680/#review9056 -----------------------------------------------------------
This patch looks ok to me, as it seems we're more-or-less implementing sleep functionality for the blocked process, but I have a couple of questions: 1) Can you expand on your statement that this supports retries without affecting system state? What state are you referring to? Certainly the number of simulated cycles, etc. will be updated as the blocked process waits. 2) Do you have any feeling for how this will affect apps that poll on some of the syscalls? E.g., if the syscall would have returned EAGAIN (or similar) will this no longer be exposed to the calling app? - Tony Gutierrez On Nov. 7, 2016, 3: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, 3: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 [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
