Pandora Could We Apply Some Of These Tips For A Ssd Laptop To The Pandora?

[iain.dalton]

http://kernelslacker.livejournal.com/132087.html

] After installing, change the fstab so that everything gets mounted with noatime. Writes to the disk are just painful, so minimising them is the path to success here. It's doubtful that you'll be running anything on an eee that would actually care about atimes anyway.
[/LIST]

http://ask.slashdot.org/comments.pl?sid=10...mp;cid=25982309

use the "noop" IO/Scheduler with nilfs:
echo noop > /sys/block/sdX/queue/scheduler

 

[Vorporeal]

Yeah, all of those would be good ideas to use with the Pandora.

There was a lot of discussion a while back about using swap - I'm not sure what came of it. Having twice the RAM now would definitely minimize the need for swap though.

 

[iain.dalton]

Does Ångström have these distributions, or is it up to the dev team to enable them in the image that's going on the Pandoras? If the latter, does the team plan to use any of these strategies?

 

[EdCa22]

These are generic linux things that can be set up in any normal distro - including Angstom

EDIT: About swap: if you're doing lots of compilation or something like that it may be beneficial to have swap on a spare SD card that you don't mind wearing out (i.e. don't store important files on it). Even though it will be really slow, if you run out of RAM while compiling then it's game over, you're stuck without being able to compile whatever it is. However, this will only happen with very large builds. Since the Pandora is so powerful, unless I get a BeagleBoard I will probably do most of my dev work on the device itself. Partly this is convienience but I also don't much like setting up cross-compilers.

 

[viridior]

While building the install image for the gentoo-arm-pandora project we have looked at a lot of the different things we can do to alleviate as much as possible from the NAND/SDHC to maximize performance and useability for most users. Without going into too many specifics there are a lot of things we can modify from a "normal" distro install that may make Linux on the Pandora function "better" for emulators and generic use. Some of these modifications could be considered either from a 'embedded' or 'laptop' approach. The gentoo-arm-pandora project is using a mix of both and we will look closely at what is delivered from the Angstrom and Ubuntu official releases.

Here is a impromptu list of things that may be considered for change from a "normal" distro install
[compilation]
- distcc
- precompiled binaries
- install host (via nfs, unionfs, samba, chroot)
- cross compilation
[removal or remapping of <swap>]
[embedded]
- busybox vs. coreutils, and others
- kdrive/minimal x.org
- small service alternative vs. "standard" programs (udhcp vs. dhcpcd/pump, dropbear vs. openssh)
- touchscreen wrappers/configurations
- non-ethernet connectivity alternatives (excluding wireless)
[laptop]
- tuxonice?
- battery monitoring
- non-standard key mappings
- wireless configs
- interconnectivity tools (avahi/zeroconf, samba, nfs, openafs, vnc, rdesktop, ...)

This list is not intended to be all inclusive but may be a start of discussions about standard software and possible alternatives that may be added or removed to minimize space useage but add capability.

Respectfully,
Viridior

 

[Yannick]

imho

I'd go for ext4, it has alot of new functionality funtionality, and is marginally faster then ext3 (there is a benchmark test on phoronix)
considering a large SD card will be filled by a mix of huge files (media) and small files (tilemaps for games)
ReiserFS might be a good choice

We need pandora's to do benchmarks

I agree with noatime, were not running a server here, no need to be that precise. <= Best desktop linux PC tweak ever

about swap, I agree, the default linux for pandora can't have swap by default (as there is no physical place to put it, lulz)
Saying you can't use swap on SD because your SD will die is just plain stupid, SD uses wear leveling. It doesn't matter how you use your SD card, if you use it a lot, it will die within 2 years.

I am putting SWAP on my custom ubuntu/gentoo/whatever, because going over a load of 256 MB without a kernel panic is a nice thing to have.
what you want to do is set this => /proc/sys/vm/swappiness to 0 then your kernel wont swap unless it is absolutely necessary to ensure the stability of your system. 5 or 10 might be a more realistic value tough


anyhow, i expect a flood of "tune your pandora for killer performance" posts on this board around january

 

[iain.dalton]

anyhow, i expect a flood of "tune your pandora for killer performance" posts on this board around january

True, but it would be nice to ship it with intelligent defaults.

 

[cb88]

and what of flash filesystems? have we forgotten those?

an option to run in "poor man " mode writing changes to ram saving theme at the end of the session and mounting them on a COWFS or unionfs layer might be somthing to look into

 

[Svartalf]

http://kernelslacker.livejournal.com/132087.html

] Next, the default filesystem will be ext3. You really don't want this. Given the journal is in a fixed location on disk, scribbling to it every time a file gets written is a great way to wear out the flash. Go with ext2. (Given that you've only got a few GB of flash anyway, a fsck doesn't take that long should you need to). Additionally, not having to write to the journal means that you're doing less IO, which is obviously a win when it's on such slow media.
[/LIST]

Heh... The story's considerably different. If you were talking traditional flash, this would be the case. However, you're talking an SSD on things like an eeePC. They do wear leveling, which changes where the writes go to the flash at a given time- so pushing out the journal doesn't put it in the same place like it's described. For an SD, it's making it do more work, which is actually ill advised. EXT2 is probably a better idea if you're not formatting it FAT32 for compatibility with everything out there. Now, the NAND will not be able to use anything other than JFFS2, which does journalling, wear-leveling, etc. It's still not a nifty idea to do a raftload of writes to it as it'll shorten the life from 5-10 years to something like 2-ish. Having said this we turn to...

QUOTE

] This should go without saying - no swap. Not only for the flash wear problem in the previous bullet, but also, because it's slow as all hell. If you find you run out of ram and get stuff oom-killed in this setup, well, you probably need to add more ram, or consider a real laptop.
[/LIST]

Not unsound thinking for the NAND. However, putting a swapfile on either an EXT2 or a FAT32 filesystem on your SD/SDHC isn't half bad an idea and will allow the 256Mb to do more for you. Keep in mind, 3D, when it comes available will take from that for textures, etc. so you might need 256Mb of an SD card set aside as swapfile. It won't wear out the flash any faster than one would expect (MLC SSD's have roughly a 10Gb per day throughput for 10+ years before the drive's "done"...SLC SSD's go even further. Ditto the SDHC's...) so it's not a big deal, esp. if you properly back things up every once in a while like you're supposed to anyhow.

QUOTE

] After installing, change the fstab so that everything gets mounted with noatime. Writes to the disk are just painful, so minimising them is the path to success here. It's doubtful that you'll be running anything on an eee that would actually care about atimes anyway.
[/LIST]

Most things won't get broken here- it's used to help things like make, etc. better keep track of when something was accessed. Killing that update to the filesystem will speed things up and won't mess up even makes in many cases if you're crazy like I am and do development things on devices like a Pandora.

QUOTE

use the "noop" IO/Scheduler with nilfs:
echo noop > /sys/block/sdX/queue/scheduler


Leave the schedulers ALONE. Unless you precisely know what you're doing with the innards of the kernel, you can seriously break other things.

True, but it would be nice to ship it with intelligent defaults.

Indeed. It's the plan.