Jump to content


Photo

Running android in ram?

- - - - -

  • Please log in to reply
54 replies to this topic

#41
Luke2642

Luke2642

    Newbie

  • Members
  • Pip
  • 29 posts
Can anyone see any problems making a TPT zip without a system or cache partitions all together? I've slimmed down and tar.gz'd the system partition image to about 60mb... I'll make the boot partition 60mb bigger add the system image, and mount it in ram like you've been discussing. A few meg in ram for cache & dalvik-cache.

I bet we can get somewhere near to 450mb space in /data for apps! And by keeping system as small as possible, it'll not use much ram or take much time to boot either :P

  • 0

#42
IronDoc

IronDoc

    Addict

  • MoDaCo Silver
  • PipPipPipPipPip
  • 522 posts
  • Devices:Blade

Can anyone see any problems making a TPT zip without a system or cache partitions all together? I've slimmed down and tar.gz'd the system partition image to about 60mb... I'll make the boot partition 60mb bigger add the system image, and mount it in ram like you've been discussing. A few meg in ram for cache & dalvik-cache.

I bet we can get somewhere near to 450mb space in /data for apps! And by keeping system as small as possible, it'll not use much ram or take much time to boot either :P

Cache is needed to download apps. They go in there temporarily.

  • 0

#43
Luke2642

Luke2642

    Newbie

  • Members
  • Pip
  • 29 posts

Cache is needed to download apps. They go in there temporarily.

Perhaps I didn't explain that clearly... cache will be mounted in ram too. :P

It's great that ADB works even when you bugger everything up, eh! I should probably practice on the emulator first... hehe!

  • 0

#44
IronDoc

IronDoc

    Addict

  • MoDaCo Silver
  • PipPipPipPipPip
  • 522 posts
  • Devices:Blade
I don't really see the benefit of putting cache there. You'd need to reserve it some space so that would be wasted wouldn't it? Wbaw's method of putting cache in data seems better.

Edited by IronDoc, 10 February 2011 - 03:01 PM.

  • 0

#45
Luke2642

Luke2642

    Newbie

  • Members
  • Pip
  • 29 posts

I don't really see the benefit of putting cache there. You'd need to reserve it some space so that would be wasted wouldn't it? Wbaw's method of putting cache in data seems better.


Yep, much better. Must investigate how often it gets automatically cleared too... or stick it on the SD card so it doesn't matter.

The blade's 512mb internal storage... does anyone know how it's used? Adding up the hex sizes given in cat /proc/mtd and converting to decimal I still end up ~60mb short... where's the rest? Is it accessible or is it used internally (wear levelling etc) by the flash controller?

  • 0

#46
IronDoc

IronDoc

    Addict

  • MoDaCo Silver
  • PipPipPipPipPip
  • 522 posts
  • Devices:Blade

Yep, much better. Must investigate how often it gets automatically cleared too... or stick it on the SD card so it doesn't matter.

The blade's 512mb internal storage... does anyone know how it's used? Adding up the hex sizes given in cat /proc/mtd and converting to decimal I still end up ~60mb short... where's the rest? Is it accessible or is it used internally (wear levelling etc) by the flash controller?

Someone said there was like a hidden or unnamed portion iirc.

  • 0

#47
oh!dougal

oh!dougal

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,022 posts
  • Location:England
  • Devices:DX2 FroYo San Francisco

The blade's 512mb internal storage... does anyone know how it's used? Adding up the hex sizes given in cat /proc/mtd and converting to decimal I still end up ~60mb short... where's the rest? Is it accessible or is it used internally (wear levelling etc) by the flash controller?


The boot process to get linux running seems to be quite complex.
There are various partitions created that are not accessible to linux.

Also, there are various different bits of (nothing to do with, not visible to, linux) boot code for handling the plural different boot modes, including the update-flash stuff for the TPT install (which at least needs to mount the fat-formatted sdcard, and then access - or run - the data in /image). All that code has to be somewhere ...

  • 0

#48
Phoenix Silver

Phoenix Silver

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 1,839 posts
  • Gender:Female
  • Location:Strasbourg.
  • Devices:ZTE Blade Orange France
  • Twitter:@phoenixbjp

The boot process to get linux running seems to be quite complex.
There are various partitions created that are not accessible to linux.

Also, there are various different bits of (nothing to do with, not visible to, linux) boot code for handling the plural different boot modes, including the update-flash stuff for the TPT install (which at least needs to mount the fat-formatted sdcard, and then access - or run - the data in /image). All that code has to be somewhere ...

surely something like the bios in PC

  • 0
Si le corps est mortel, l’âme elle est éternelle.

#49
oh!dougal

oh!dougal

    Hardcore

  • Members
  • PipPipPipPipPipPip
  • 1,022 posts
  • Location:England
  • Devices:DX2 FroYo San Francisco

surely something like the bios in PC


Well, a bit like some bits of the BIOS ... but an important difference is that once AndroidLinux is running, it doesn't have the capability of accessing that stuff. Its done its job, and won't be needed until the next boot. I don't think its much like BIOS routines being called by MSDOS, or MSDOS programs ...

  • 0

#50
wbaw

wbaw

    account closed

  • Banned
  • PipPipPipPipPipPip
  • 1,885 posts
  • Gender:Not Telling

/cache in RAM didn't work well. It seems Market checks the free space before starting to download so it aborts and logcat shows it thinks there is no free space. The ramdisk seems to be dynamic and you can put stuff there until you run out of ram but i suppose diskfree calls doesn't work the normal way with it.


Yeah, I just tried it, didn't work well at all, market wont download anything.

I'm going to experiment with tmpfs next.

[edit] that doesn't work either - if i mount cache /cache on it's own 42m tmpfs, market still fails ... i'm sticking to symlinking to /data/cache for now.

I might have a go at repacking the kernel ramdisk, not mounting /cache & symlinking it in init.rc

Edited by wbaw, 14 February 2011 - 01:49 AM.

  • 0

#51
wbaw

wbaw

    account closed

  • Banned
  • PipPipPipPipPipPip
  • 1,885 posts
  • Gender:Not Telling
tmpfs for /cache does work! it was just a permissions problem.

these three lines will remount /cache as tmpfs

[codebox]
umount /cache
mount -t tmpfs -o size=42M,nr_inodes=42k,mode=0770 tmpfs /cache
chown system.cache /cache
[/codebox]

It appears to speed up app installs from the market, not sure it's worth the loss of ram. downloaded apks do stay there, but the max size is 42m (same as original /cache partition) so it shouldn't cause much trouble.

Edited by wbaw, 14 February 2011 - 02:12 AM.

  • 0

#52
wbaw

wbaw

    account closed

  • Banned
  • PipPipPipPipPipPip
  • 1,885 posts
  • Gender:Not Telling
I just tried doing the same for dalvik-cache, in init_qcom.sh & now it wont boot :D

Maybe redirecting dalvik-cache in init.rc might work, but i'm not sure how sensible it'd be.

Putting /cache on a ramdrive works well.

Edited by wbaw, 15 February 2011 - 07:07 AM.

  • 0

#53
wbaw

wbaw

    account closed

  • Banned
  • PipPipPipPipPipPip
  • 1,885 posts
  • Gender:Not Telling

Can anyone see any problems making a TPT zip without a system or cache partitions all together? I've slimmed down and tar.gz'd the system partition image to about 60mb... I'll make the boot partition 60mb bigger add the system image, and mount it in ram like you've been discussing. A few meg in ram for cache & dalvik-cache.

I bet we can get somewhere near to 450mb space in /data for apps! And by keeping system as small as possible, it'll not use much ram or take much time to boot either :D


A few problems ...

/cache is used by the recovery programs (clockwork, etc) to store logs, it gives errors if it can't mount it. it's unlikely you'll ever need those logs & it doesn't affect how it works, it just gives error messages. the minimum size for the cache partition to mount correctly appears to be somewhere between 1mb & 1.5mb (1.5mb works, 1mb doesn't, didn't try intermediate sizes).

Even if you don't care about those errors, the partition still needs to be there, because the only way we can edit the partition size at the moment is hexediting a file. so i think it has to be 128k minimum, same for any other partitions.

There are hidden partitions using some nand space too, about 40mb if I remember right, the stuff in those partitions seems to be vital & we don't know enough to risk changing that. Maybe if somebody wants to risk bricking their phone we could get another 15mb or so from there & it might work, but it runs a serious risk of totally bricking the phone.

So you wont get over 400mb /data without putting your system on the sdcard.

However it seems like an interesting idea for speed, that would seem to be the fastest way to do it to me, increase the boot partition size & pack system in the kernel ramdisk.

Edited by wbaw, 15 February 2011 - 07:27 AM.

  • 0

#54
ztedd

ztedd

    Regular

  • Members
  • PipPip
  • 85 posts
  • Devices:ZTE OCH_P_P729BV1.0.0B01

I just tried doing the same for dalvik-cache, in init_qcom.sh & now it wont boot :D

Maybe redirecting dalvik-cache in init.rc might work, but i'm not sure how sensible it'd be.

Putting /cache on a ramdrive works well.

Are you sure it doesn't boot at all? Because by just moving the dalvik-cache location, the boot will be very slow as it has to create all those dalvik files. You could copy the files in dalvik-cache on each boot, that should be faster.

Would be worth a try, with stopping the exact apps startup times (using a stop watch) and comparing that to dalvik-cache on internal rom.

  • 0

#55
wbaw

wbaw

    account closed

  • Banned
  • PipPipPipPipPipPip
  • 1,885 posts
  • Gender:Not Telling

Are you sure it doesn't boot at all? Because by just moving the dalvik-cache location, the boot will be very slow as it has to create all those dalvik files. You could copy the files in dalvik-cache on each boot, that should be faster.

Would be worth a try, with stopping the exact apps startup times (using a stop watch) and comparing that to dalvik-cache on internal rom.


You can't copy the dalvik cache files on boot if you put it on a ramdisk, unless you save them when you shut down.

I'm sure it didn't work for me, when I tried it, I only tried it once. I left it for 20 minutes, it wasn't going to boot.

I'm not sure what stopped it working, it might even have been something as simple as a permissions problem (although i think i set it right). I'm not saying it's impossible, but I failed & I'm not trying again.

After I'd got my phone booting again (by reflashing the previous config file in clockwork). The phone had forgotten most of my settings, it was back to default wallpaper, no icons on home screens & it'd lost a lot of my other settings.

Added to that I'm sceptical that it'd improve performance at all, it's probably a waste of time & will hurt more than it helps.

Feel free to try it if you want, if it works it probably wont help performance (more likely to hurt it), if it doesn't it'll mess up all the settings on your phone & you'll need to restore a nandroid backup.

I've also noticed that there is a startup script in the full version of flb-froyo 8, but not in the slim version, /system/etc/init.d/02cachedalvikcache It looks like that script copies the dalvik cache to /cache. I haven't tried it in combination with my script that puts /cache on a ramdisk yet. That's probably the easiest way to test it. It might not work & even if it does it might not be a good idea.

Edited by wbaw, 17 February 2011 - 01:02 AM.

  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users