An other condition is to use an image with the smallest memory print as
possible ....
I think opkg and user applications can have more memory for their use.


Mike Westerhof (mwester) a écrit :
> Fate wrote:
>   
>> On Fri, Jul 24, 2009 at 4:52 PM, Ole Carlsen <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>     Hi
>>     Where would be the best place to put a swap file / partition? On the
>>     mmc? I have tried to follow the instruction on
>>     http://wiki.openmoko.org/wiki/SHR#opkg_upgrade_.22fork_failed.22 but I
>>     keep getting a resource busy message, so I thought of making it
>>     permanent and add it in fstab.
>>
>>     If a swap file is a benefit why isn't it part of standard images then??
>>
>>
>> it wears down the memory card, a lot of writes and reads...
>>     
>
> Hopefully it will never be actually used.
>
> Linux uses a "copy-on-write" technique to ensure that duplicate memory
> doesn't actually get duplicated until one process changes it.  So the
> swapfile satisfies the requirement that sufficient virtual memory is
> available for the worst case; in fact opkg (like almost every app using
> fork() in existence) does not ever cause the memory to be copied, as the
> child process never actually modifies but a few pages of the memory
> duplicated from the parent.
>
> Adding a swapfile is a reasonable short-term workaround for the bad opkg
> behavior.
>
> Changing the Out-of-memory killer behavior is also an option, although
> not good practice: use sysctl to set vm.overcommit_memory to "1" which
> will allow the system to overcommit memory without limit.
>
> These are just short-term workarounds, and won't fix opkg's bad behavior
> in all cases, just in many cases.  To fix opkg for all situations will
> require the patches I mentioned in an earlier email.
>
> Mike (mwester)
> _______________________________________________
> Shr-User mailing list
> [email protected]
> http://lists.shr-project.org/mailman/listinfo/shr-user
>
>
>   

_______________________________________________
Shr-User mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-user

Reply via email to