blob: f196ac1d7d2526507a55ff6bc70f903fcc9ee56d [file] [log] [blame]
Pavel Emelyanovfaebe9f2008-04-29 01:00:18 -07001
2 The Resource Counter
3
4The resource counter, declared at include/linux/res_counter.h,
5is supposed to facilitate the resource management by controllers
6by providing common stuff for accounting.
7
8This "stuff" includes the res_counter structure and routines
9to work with it.
10
11
12
131. Crucial parts of the res_counter structure
14
15 a. unsigned long long usage
16
17 The usage value shows the amount of a resource that is consumed
18 by a group at a given time. The units of measurement should be
19 determined by the controller that uses this counter. E.g. it can
20 be bytes, items or any other unit the controller operates on.
21
22 b. unsigned long long max_usage
23
24 The maximal value of the usage over time.
25
26 This value is useful when gathering statistical information about
27 the particular group, as it shows the actual resource requirements
28 for a particular group, not just some usage snapshot.
29
30 c. unsigned long long limit
31
32 The maximal allowed amount of resource to consume by the group. In
33 case the group requests for more resources, so that the usage value
34 would exceed the limit, the resource allocation is rejected (see
35 the next section).
36
37 d. unsigned long long failcnt
38
39 The failcnt stands for "failures counter". This is the number of
40 resource allocation attempts that failed.
41
42 c. spinlock_t lock
43
44 Protects changes of the above values.
45
46
47
482. Basic accounting routines
49
50 a. void res_counter_init(struct res_counter *rc)
51
52 Initializes the resource counter. As usual, should be the first
53 routine called for a new counter.
54
55 b. int res_counter_charge[_locked]
56 (struct res_counter *rc, unsigned long val)
57
58 When a resource is about to be allocated it has to be accounted
59 with the appropriate resource counter (controller should determine
60 which one to use on its own). This operation is called "charging".
61
62 This is not very important which operation - resource allocation
63 or charging - is performed first, but
64 * if the allocation is performed first, this may create a
65 temporary resource over-usage by the time resource counter is
66 charged;
67 * if the charging is performed first, then it should be uncharged
68 on error path (if the one is called).
69
70 c. void res_counter_uncharge[_locked]
71 (struct res_counter *rc, unsigned long val)
72
73 When a resource is released (freed) it should be de-accounted
74 from the resource counter it was accounted to. This is called
75 "uncharging".
76
77 The _locked routines imply that the res_counter->lock is taken.
78
79
80 2.1 Other accounting routines
81
82 There are more routines that may help you with common needs, like
83 checking whether the limit is reached or resetting the max_usage
84 value. They are all declared in include/linux/res_counter.h.
85
86
87
883. Analyzing the resource counter registrations
89
90 a. If the failcnt value constantly grows, this means that the counter's
91 limit is too tight. Either the group is misbehaving and consumes too
92 many resources, or the configuration is not suitable for the group
93 and the limit should be increased.
94
95 b. The max_usage value can be used to quickly tune the group. One may
96 set the limits to maximal values and either load the container with
97 a common pattern or leave one for a while. After this the max_usage
98 value shows the amount of memory the container would require during
99 its common activity.
100
101 Setting the limit a bit above this value gives a pretty good
102 configuration that works in most of the cases.
103
104 c. If the max_usage is much less than the limit, but the failcnt value
105 is growing, then the group tries to allocate a big chunk of resource
106 at once.
107
108 d. If the max_usage is much less than the limit, but the failcnt value
109 is 0, then this group is given too high limit, that it does not
110 require. It is better to lower the limit a bit leaving more resource
111 for other groups.
112
113
114
1154. Communication with the control groups subsystem (cgroups)
116
117All the resource controllers that are using cgroups and resource counters
118should provide files (in the cgroup filesystem) to work with the resource
119counter fields. They are recommended to adhere to the following rules:
120
121 a. File names
122
123 Field name File name
124 ---------------------------------------------------
125 usage usage_in_<unit_of_measurement>
126 max_usage max_usage_in_<unit_of_measurement>
127 limit limit_in_<unit_of_measurement>
128 failcnt failcnt
129 lock no file :)
130
131 b. Reading from file should show the corresponding field value in the
132 appropriate format.
133
134 c. Writing to file
135
136 Field Expected behavior
137 ----------------------------------
138 usage prohibited
139 max_usage reset to usage
140 limit set the limit
141 failcnt reset to zero
142
143
144
1455. Usage example
146
147 a. Declare a task group (take a look at cgroups subsystem for this) and
148 fold a res_counter into it
149
150 struct my_group {
151 struct res_counter res;
152
153 <other fields>
154 }
155
156 b. Put hooks in resource allocation/release paths
157
158 int alloc_something(...)
159 {
160 if (res_counter_charge(res_counter_ptr, amount) < 0)
161 return -ENOMEM;
162
163 <allocate the resource and return to the caller>
164 }
165
166 void release_something(...)
167 {
168 res_counter_uncharge(res_counter_ptr, amount);
169
170 <release the resource>
171 }
172
173 In order to keep the usage value self-consistent, both the
174 "res_counter_ptr" and the "amount" in release_something() should be
175 the same as they were in the alloc_something() when the releasing
176 resource was allocated.
177
178 c. Provide the way to read res_counter values and set them (the cgroups
179 still can help with it).
180
181 c. Compile and run :)