agios.conf

library_options:
{
	#should we generate trace files during execution? (this will be slow, don't use when evaluating performance) 
	trace = false ;

	#prefix and sufix for trace files (with path). Their names must be trace_file_prefix+"."+number+"."+trace_file_sufix, with ordered numbers (no holes)
	trace_file_prefix = "/tmp/agios_tracefile"
	trace_file_sufix = "out"

	#maximum buffer size used for storing trace parts (in KB). Having a buffer avoids generating requests to the local file system, which causes interference in performance. On the other hand, having a large buffer can affect performance and decrease available space for data buffer.
	max_trace_buffer_size = 32768 ;

	#parameters used by aIOLi and MLF
	# waiting time in ns, stored in an integer (so the maximum is of approximately 2 seconds). quantum in bytes
	waiting_time = 900000
	aioli_quantum = 65536
	mlf_quantum = 8192

	#parameter used by SW (ms).
	SW_window = 1000 #the paper proposing TW (Song et al. 2013) recommends 1000 for HDD and 250 for SSD.

	#parameter used by the TWINS algorithm (in us). Stored in ns in an integer, so the maximum is of approximately 2 seconds
	twins_window = 2000 

	#to how many scheduling algorithms the performance module keeps measurements. When we are changing scheduling algorithms, we may observe new measurements (through the agios_release_request function) to the previous algorithms, so we could update information we have for them. It makes no sense to have a big value for performance_values if we don't change algorithms too often
	performance_values = 5

	#default I/O scheduling algorithm to use 
	#existing algorithms (case sensitive): "MLF", "aIOLi", "SJF", "TO", "TO-agg", "SW", "NOOP", "TWINS" (case sensitive) 
	# NOOP is the "no operation" scheduling algorithm, requests are given back to the user as soon as they arrive to the library (internal statistics are still updated, could be use to generate a trace, for instance)
	# SW only makes sense if the user is providing AGIOS with the correct application id for each request. Don't use it otherwise
	default_algorithm = "SJF" ;

	# select_algorithm_period, in ms, is only relevant if default_algorithm is a dynamic scheduler. This parameter gives the frequency to choose a new scheduling algorithm. This selection will be done using the access pattern from this period. If -1 is provided, then the selection will be done at the beginning of execution only 
	# The next parameter gives the minimum number of requests that need to be executed in this period for the re-selection to be done (otherwise we will wait longer before changing the scheduling algorithm).  
	select_algorithm_period = 1000
	select_algorithm_min_reqnumber=1

	# This parameter is also for dynamic algorithms. says if SW should be one of the options considered by the dynamic scheduler. SW requires identifying requests according to the applications they come from. If this is not possible, don't use SW!
	enable_SW = false ;

	# If the default_algorithm is a dynamic scheduler, you need to indicate which static algorithm to use first (before automatically selecting the next one). 
	starting_algorithm = "SJF" ;

	# If the scheduling algorithm is the WFQ, you need to indicate the full path to the wfq.conf file.
    wfq_conf = "/tmp/wfq.conf" ;
};