[maemo-developers] [maemo-developers] Huge bundle O' year-end questions

[From: Paul Mundt]

On Sat, Dec 31, 2005 at 02:53:19AM -0800, Jason Mills wrote:
> OMAP1710:
> * How does one get access to the hardware Random Number Generator? (Is
> that what /dev/urandom is pinned to?)
> 
Via the RNG driver. Look at drivers/char/hw_random.c as well as
omap16xx-rng.c if you want to know how it's handled.

> * Would it, in that context, be advisable to separate the OMAP1710 from
> the earlier bretheren (OMAP16xx f'rexample) when dealing with the Linux
> - ARM9 - OMAP1xxx kernel branch, since they feature radically different
> cache sizes and value-add functionality?
> 
Why? The cache size is irrelevant, the same semantics apply to both.

grep for cpu_is_omap1710(), there's incredibly few instances where 1710
differences matter.

> * I noticed that the kernel was compiled using "optimize for size"
> (-Os) rather than "optimize for speed" (-O2 or -O3), which seems to be
> the correct methodology for ARM9, assuming it has the same cache size
> issues that the IA-32 Centaur does... "optimize for size" actually
> yields faster code, since you end up with fewer cache-misses. Why isn't
> the same optimization recommended for ported applications?
> 
There's not much point, ARM9 has a non-coherent VIVT L1, so we have to
write-back and invalidate the dcache on every context switch anyways, so
applications will simply all miss after every context switch regardless
of what kind of cacheline utilization they are after. Lack of proper ASID
tags is a source of constant irritation.

In the x86 case it's not too surprising that those sorts of optimizations
would be meaningful, since there's variable length instruction encoding,
and the alignment constraints are completely different. None of that
applies to ARM, and the code density is already quite good. It might be
worthwhile padding out some commonly used structures in userspace out to
cacheline boundaries, but given the fact that it's all blown away after
every context switch, it wouldn't be of much benefit.

> * I also noticed that the kernel had a number of debug features set,
> which (IIRC!) slow the kernel down and add bloat, no? (CONFIG_DEBUG,
> CONFIG_FRAME_POINTER, etc...)
> 
This isn't x86. Outside of x86 land there are plenty of architectures
that require frame pointer support in order to do stack backtraces. ARM,
sh64, and if I recall correctly, ia64, are all in this camp.

Feel free to turn it off if you wish, but note that no one will take any
bug reports ;-)

> Memory:
> * Why does RAM fragment -so- quickly and so badly? I can go from ~5% to
> ~60% by just launching a single application.
> 
How does this have anything to do with memory fragmentation? Unused
memory is wasted memory.

> * Does the ARM9 architecture suffer a large performance penalty for
> fragmentation like this? (user perception says yes, but...)
> 
This also has nothing to do with ARM, but yes, the VM performance suffers
when memory starts to fragment badly. If you're interested in playing
around with some alternatives to warding off fragmentation, look at some
of the work done by the memory hotplug guys.

As an example, we currently need to pre-allocate physically contiguous
page frames for the DSP early on in boot time in order to satisfy
contiguity of a high order (for large shared buffers mapped through both
MMUs into the DSP and ARM address spaces). After userspace applications
start abusing the system (particularly certain applications that go out
of their way to abuse overcommit), it's no longer possible.

One could logically infer that performance in general would take a hit as
a result of this.

> Time:
> * Is there direct RTC access?
> 
Yes, but not in the way you want.

> * Could "auto wake" be achieved by setting the RTC timer alarm for a
> future point in time, and then running a suspend-to-ram operation?
> 
Alarms are settable through sysfs. retu-rtc is what you are after. Look
at drivers/cbus/retu-rtc.c in the kernel source if you want additional
information, it's rather self explanatory.