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. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
