Dave,<br><br>For the case of NEON and its use in graphics libraries, we are certainly pushing explicitly for runtime detection. However, this tends to be done by detecting the presence of NEON at initialization time, rather than at each path invocation (to avoid rescanning /proc/self/auxv). Are you saying that the init code could still detect NEON this way, but there would need to be additional checks when taking individual paths?<br>
<br>cheers,<br>Jesse<br><br><div class="gmail_quote">On Fri, Dec 3, 2010 at 8:28 AM, Dave Martin <span dir="ltr"><<a href="mailto:dave.martin@linaro.org">dave.martin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi all,<br>
<br>
I'd be interested in people's views on the following idea-- feel free<br>
to ignore if it doesn't interest you.<br>
<br>
<br>
For power-management purposes, it's useful to be able to turn off<br>
functional blocks on the SoC.<br>
<br>
For on-SoC peripherals, this can be managed through the driver<br>
framework in the kernel, but for functional blocks of the CPU itself<br>
which are used by instruction set extensions, such as NEON or other<br>
media accelerators, it would be interesting if processes could adapt<br>
to these units appearing and disappearing at runtime. This would mean<br>
that user processes would need to select dynamically between different<br>
implementations of accelerated functionality at runtime.<br>
<br>
This allows for more active power management of such functional<br>
blocks: if the CPU is not fully loaded, you can turn them off -- the<br>
kernel can spot when there is significant idle time and do this. If<br>
the CPU becomes fully loaded, applications which have soft-realtime<br>
constraints can notice this and switch to their accelerated code<br>
(which will cause the kernel to switch the functional unit(s) on).<br>
Or, the kernel can react to increasing CPU load by speculatively turn<br>
it on instead. This is analogous to the behaviour of other power<br>
governors in the system. Non-aware applications will still work<br>
seamlessly -- these may simply run accelerated code if the hardware<br>
supports it, causing the kernel to turn the affected functional<br>
block(s) on.<br>
<br>
In order for this to work, some dynamic status information would need<br>
to be visible to each user process, and polled each time a function<br>
with a dynamically switchable choice of implementations gets called.<br>
You probably don't need to worry about race conditions either-- if the<br>
process accidentally tries to use a turned-off feature, you will take<br>
a fault which gives the kernel the chance to turn the feature back on.<br>
Generally, this should be a rare occurrence.<br>
<br>
<br>
The dynamic feature status information should ideally be per-CPU<br>
global, though we could have a separate copy per thread, at the cost<br>
of more memory. It can't be system-global, since different CPUs may<br>
have a different set of functional blocks active at any one time --<br>
for this reason, the information can't be stored in an existing<br>
mapping such as the vectors page. Conversely, existing mechanisms<br>
such sysfs probably involve too much overhead to be polled every time<br>
you call copy_pixmap() or whatever.<br>
<br>
Alternatively, each thread could register a userspace buffer (a single<br>
word is probably adequate) into which the CPU pokes the hardware<br>
status flags each time it returns to userspace, if the hardware status<br>
has changed or if the thread has been migrated.<br>
<br>
Either of the above approaches could be prototyped as an mmap'able<br>
driver, though this may not be the best approach in the long run.<br>
<br>
<br>
Does anyone have a view on whether this is a worthwhile idea, or what<br>
the best approach would be?<br>
<br>
Cheers<br>
---Dave<br>
<br>
_______________________________________________<br>
linaro-dev mailing list<br>
<a href="mailto:linaro-dev@lists.linaro.org">linaro-dev@lists.linaro.org</a><br>
<a href="http://lists.linaro.org/mailman/listinfo/linaro-dev" target="_blank">http://lists.linaro.org/mailman/listinfo/linaro-dev</a><br>
</blockquote></div><br>