Ingo Molnar wrote:
quoted text
>> The main goal was to avoid allocating 4096 bytes when only 32 would do 
>> (characters needed to represent nr_cpu_ids cpus instead of NR_CPUS 
>> cpus.) But I'll look at cleaning it up a bit more.  It wouldn't have 
>> to be a function if CHUNKSZ in cpumask_scnprintf() were visible (or a 
>> non-changeable constant.)
> 
> well, do we care about allocating 4096 bytes, as long as we also free 
> it? It's not like we need to clear all the bytes or something. Am i 
> missing something here?

Well, 32 bytes fits on the stack, whereas 4096 bytes requires allocating 
a page -- which means either taking the risk of failing or blocking.  Of 
course, we're doing this for output, which has the same issue.

	-hpa
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/