#
# WinAFC Input File
#
# Lines that start with a '#' and empty lines are ignored. 
# Configuration lines include global flag setting lines, and application profile
# lines. These lines can be interleaved in any order. However, the order in which
# you specify the various application profiles matters if a process could be
# matched by multiple application profiles.

# To run AffinityChanger in TestMode (no affinity settings are modified),
# uncomment the line below and specify a value different than zero. To disable 
# test mode, set the value to 0 or comment the line below.
# It is recommended that you try the input file in test mode first, after you
# make changes, especially if you are unfamiliar with the syntax.
TestMode = 1

# There are several flags that control the verbosity of the program. 
# In general, a higher value means a more verbose output. These flags can 
# be also modified at run-time.

# By default the warning level is set to 2. To change it, uncomment the next 
# line and specify a value>=0. Zero disables warning messages (not recommended).
#WarningLevel = 2

# Logging is done on both console and in a file called 'affinitylog.txt'. 
# Separate flags control the verbosity for each medium. By default the logging
# level is set to 3. Uncomment the next lines to change the values of these 
# flags.
# To change only the console verbosity:
#ConsoleLogLevel = 3
#
# To change only the file verbosity:
#FileLogLevel = 3
#
# To change both mediums at the same time:
#LogLevel = 3

# By default AffinityChanger checks for new processes every 30 seconds.
# To change how frequently AffinityChanger checks for new processes or adjusts
# affinities for existing processes, uncomment the line below and specify the
# number of seconds between consecutve process checks. The minimum accepted 
# value is 1 and the value can be only an integer number.
#TimeInterval = 30

# One can change the value of a flag multiple times. In these cases the 
# most recently specified value will take effect.
#

##################################################
##          Application Profile lines
##################################################
#
# An application profile is specified on a single line. 
# An application profile includes the following information: an application
# name, a CPU mask, and optional attributes in the following format:
# C:\Path\To\Application := CPU0+CPU1 [attr1=val1,attr2=val2]
#
# Check the documentation for more information about these fields.

# While AffinityChanger does not target any particular application, its
# initial development was motivated by the Folding@Home project. Therefore,
# I will provide several Application Profile examples inspired by the FAH
# project.

# This example assume a machine with an Intel Quad Core CPU for which 
# AffinityChanger detected the two PAIRs of cores that share the L2 cache. 
# All profiles use logical CPU IDs in the CPU mask.

# In this scenario the user runs one Windows SMP client, one process per core.
# In this case, the optimum process assignment would be to use a balancing 
# policy that offers the best utilization of the shared L2 caches.

# We want to assigne the process with the largest working set and the process
# with the lowest working set to cores on the same die. The middle two 
# processes should be assigned to the second die.
# We can write this policy as follows:
D:\Folding@Home\FAH6.22-win32-SMP\FahCore_*.exe := PAIR0::CPU1+PAIR1+PAIR0::CPU0 [assign=1,resource=MEMUSE,policy=PSEUDOBALANCED]

# Make sure that the profile definition is not split onto multiple lines or 
# the parser will generate an error. Notice how we used a wildcard to match 
# any core that the Stanford people might throw at us.

# Notice also how we specified the CPU mask. By using a balancing policy 
# and the resource=MEMUSE attribute, processes are sorted by the amount 
# of memory they use. They are assigned to CPUs, one CPU per process, in the 
# order in which CPUs are listed. 
# As a result, the largest process will be assigned to PAIR0::CPU1, next two 
# processes are assigned to PAIR1::CPU0 and PAIR1::CPU1, and the smallest 
# process is assigned to PAIR0::CPU0.

# This is the optimal theoretical assignment for this scenario. However, 
# I have no idea if it will make a significant difference in practice 
# compared to a random assignment of one process per CPU. In any case, 
# there should be no other assignment that would do better with a single SMP 
# client on an Intel Quad.

#
# You should try any scenario under the TestMode first to verify that it
# does what you expect.
#