Closed GoogleCodeExporter closed 8 years ago
As you may know the kernel is not a part of this release because the Milestone
bootloader only loads a kernel that has been signed by a (secret) key. Because
of this fact no one else will be able to provide a kernel that is able to
support swap support. I doubt this could be done by a module but things
happen...
Original comment by bodorif...@gmail.com
on 27 Oct 2010 at 9:09
My understanding is.. 2nd Init able to allow us to get our own kernel (thats
why we have CM6 now). The only one we couldn't modify now is boot.img, am i
right?
Original comment by ComFla...@gmail.com
on 27 Oct 2010 at 9:23
Kernel is a part of the signed boot.img.
2nd-init allows us to use custom init and init.rc scripts in a clean way.
2nd-boot would allow us to use a custom kernel, but the ultimate modem panic
during kernel restart haven't been resolved yet.
Therefore we are still bound to use only the kernels compiled and signed by
Motorola.
Original comment by kabal...@gmail.com
on 27 Oct 2010 at 10:46
Thanks nadlabak for xplaination. Hope 2nd boot become reality, so we could have
better custom kernel
Original comment by ComFla...@gmail.com
on 27 Oct 2010 at 11:37
Original comment by kabal...@gmail.com
on 5 Nov 2010 at 11:42
Hey Pavel!
We got some discussion going on regarding this topic here:
http://www.android-hilfe.de/root-hacking-modding-fuer-motorola-milestone/53575-d
iskussion-256-mb-ram-zu-wenig-swap.html
Question: As the kernel does not support swapping, is there something as a
"swap.ko", that could be ripped somewhere (Droid2, X, Nexus, whereever) and
injected into the milestone? As done for openVPN, governors, overclocking, etc.?
As a background: SD-card nearly reads at double data rate than internal flash
memory. So to increase I/O Performance one could copy as much as possible on
the SD-card and remount/relink it there (e.g. /data/... /system/...
/cache/...). But this will cause a lot of problems, e.g. during mounting the SD
card over USB as a mass storage device. Also the data would have to be copied
on every boot -> sloooow. Nice and direct workaround to make use of the
increased data rate would be a swap memory of e.g. 128 MB or similar. I bet it
would be faster than loading everything from the slow internal NAND flash.
As a comparison (using "J Bench Mark"): On my milestone with 8 kb buffer:
Internal Flash: 0,5 MB/sec write 3,5 MB/sec read
SD card: 3,5 MB/sec write 6,5 MB/sec read
(it's a class 6 SD card)
BR!
PS: I WISH my programming skills would be better and I could search for a
solution on my own. I always feel awkward asking such stuff to "nadlabak
again", who got his baby, family, CM6 etc. going on in parallel.
Original comment by doc.pa...@gmail.com
on 11 Nov 2010 at 11:27
Some parts of the kernel source are ready to be compiled either as a direct
part of the kernel or as a loadable module. So, compiling the modules for
kernel is quite easy (although sometimes the sources need to be patched to work
correctly with the particular kernel). Btw., the modules are not being ripped
from other phones, they are simply compiled from sources.
But some parts of the kernel source are only to be compiled as a direct part of
the kernel - eg. the swap support. Remaking of such parts to a module is not an
easy task. That is because a direct part of a kernel has access to all kernel
symbols (functions, data structures), while a module has access only to those
symbols that have been specifically exported to be available for use from
modules.
Although there are ways to make the unexported symbols available in modules by
finding the direct addresses of them in /proc/kallsyms - that is btw. used in
the overclock and interactive governor modules (the addresses supplied to the
modules as parameters are the addresses of the very symbols that need to be
used but have not been exported for modules by kernel).
The swap code integration in the kernel is very complex. Separating it to a
module would need excessive amount of work, while I'm not sure if it is at all
possible, given the fact that the module would not be present in the kernel
from the start, but only later when the first insmod command can be executed...
Original comment by kabal...@gmail.com
on 11 Nov 2010 at 12:06
[deleted comment]
-> :P :P :P
Thnx for that explanation!
Original comment by doc.pa...@gmail.com
on 11 Nov 2010 at 12:42
Thanks kabaldan for explanations.
I understand that it would be hard to make such a module but it would be great
if a skilled dev can give it a try.
More and more memory intensive apps are coming to the market (especially games)
and i feel sooo sad to not be able to use them because of 256 MiB limitation
(example Dungeon Defenders runs great on Droid that have a custom kernel using
swap feature. The app just won't load on milestone). Even for the whole system
speed, this feature would be soo great ...
Well keep up the good work on CyanogenMod port guys !
Original comment by aurelien...@gmail.com
on 10 Jan 2011 at 10:23
swap and compcache would be great ^^
i've tried in ubuntu, compcache can compres up to 80% memory
Original comment by superbiji
on 11 Jan 2011 at 3:02
Hmm...
Adding swap will be something huge, yes.
But there are a few other things to think about:
-Put more pressure to the developer to reduce the memory-usage from their
applications. Many yust eat way too much in my oppinion.
-increse the usable ram. Why is the inactive ram so much? I don't think that
cache should be higher priority than not-killing programs...
-letting the widgets into the same VM as the homescreen. I don't think that
its's good that every widget need its own VM. Or: build some more basic infos
like IP, CPU-Freq, RAM, temperature and the like directly into the homescreen.
-Let the vm compress the addresspace from apps and safe it to the sd-card,
instead of killing them. This should be quite fast - much faster than
restarting apps all over the time. A fast compression should be quite enough.
-improve the restarting-behavior from the most important appliations like the
browser. Why do they need to reload the whole page? I think that they should
save the complete data before being killed, so that even if there are killed,
the restarting is almost not noticable.
-deactivate the kernel-OOM alltogether and let an android-process controll it.
This way we could archive much fine control which tasks are being killed - and
could do things like automatic saving their states, send "save memory" signals
to the processes and the like.
-instead of building swap in the kernel, build it in dalvik. This should be
much more easy. This should cover most processes, because on a "normal" andrid
system there aren't such many traditional linuxtasks.
Original comment by mifritsc...@gmail.com
on 19 Sep 2011 at 10:33
Yust another way: ask Motorola to build a kernel with swap ;) I think that this
is way more probably that unlocking the bootloader, at least in the next time...
Original comment by mifritsc...@gmail.com
on 20 Sep 2011 at 6:02
-stop the crappy apps2sd to mount every single app during start, but do it if
needed (for version 1.0, umounting isn't really needed I think, because after
even 5 days of usage, in most cases only a tiny part of apps are used since the
start)
-kill the oom-killer :D I've seen situation where the oom got invoked even
besides 44 of free RAM+ 60MB inactive! I think it would be worth the experiment
how far the memory managment can get if it hasn't the "tool" oom-killer... Yes,
I know, at some point it will procuce a big fat BAM, but I assume not in
normal usage situations and and atleast not in the first 5 minutes. Then we
could build our own userspace oom-killer which does kill processes only if
really needed.
Original comment by mifritsc...@gmail.com
on 20 Sep 2011 at 4:04
Issue 563 has been merged into this issue.
Original comment by kabal...@gmail.com
on 27 Nov 2011 at 12:26
wouldn't it be great if somebody like nadlaback ask motorola to get a key to
sign cyanogenmod for feature development for the milestone, maybe he will get
it, that in the future cm could get some important features.
Original comment by itgch...@googlemail.com
on 22 Feb 2012 at 10:09
Custom kernel with working gsm/umts is now possible on Milestone, see
http://forum.xda-developers.com/showthread.php?p=32512060#post32512060
and the original breakthrough thread
http://forum.xda-developers.com/showthread.php?t=1908687
There's still a lot of work to be done, but new era has been already started.
Original comment by kabal...@gmail.com
on 13 Oct 2012 at 11:53
Im trying 7.2.4 with swap enabled now.. thanks kabaldan. its working great now.
64MB swap size with compcache disabled is my sweet spot. No more reboot, FC and
minimal slowdown.
Additional Setting:
/sys/block/mmcblk0/queue/read_ahead_kb = 2048kb
VM Max Heap Size = 48MB
SDcard speed = 16GB Class 10
Original comment by ComFla...@gmail.com
on 24 Oct 2012 at 7:22
Original comment by kabal...@gmail.com
on 5 Nov 2012 at 11:30
Original issue reported on code.google.com by
ComFla...@gmail.com
on 27 Oct 2010 at 12:28