-----------------------------------------------------------
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

Reply via email to