Re: [libvirt] [PATCH 1/2] cgroup: Add accessors for cpuset.memory_migrate
On Thu, Mar 19, 2015 at 05:25:28PM -0600, Eric Blake wrote:
On 03/19/2015 05:11 PM, John Ferlan wrote:
>> +int
>> +virCgroupSetCpusetMemoryMigrate(virCgroupPtr group, bool migrate)
>> +{
>> + return virCgroupSetValueStr(group,
>> + VIR_CGROUP_CONTROLLER_CPUSET,
>> + "cpuset.memory_migrate",
>> + migrate ? "1" : "0");
>> +}
>
> are my eyes deceiving me?... boolean here (1 or 0)
No, the kernel really works this way - it takes the human-readable
string "1" or "0" rather than the C byte '\1' or '\0',
so this is the
lowest level in the stack where we convert our convenient bool for
everyone above us into the string literal the kernel cgroup interface
expects.
Yes, exactly. I could've also used SetValueU64(), but that formats
that value which is unnecessary overhead.
>> +int
>> +virCgroupGetCpusetMemoryMigrate(virCgroupPtr group, bool *migrate)
>> +{
>> + unsigned long long value = 0;
>> + int ret = virCgroupGetValueU64(group,
>
> But we're getting a U64 here? for what's documented as "contains a flag
> (0 or 1)
>
>> + VIR_CGROUP_CONTROLLER_CPUSET,
>> + "cpuset.memory_migrate",
>> + &value);
>> + *migrate = !!value;
And here, this is one easy way to turn the kernel's string back into a
bool (it might also be possible to read as a string, and then do
*str=='1', rather than going through an intermediate integer conversion,
but I'm not sure it is worth the micro-optimization).
With one exception. If kernel changes the possible values to
something else (let's say they'll add "2" for some special new
meaning like "move aggressively"), this code will still work.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachments:
- attachment.sig (application/pgp-signature — 819 bytes)