Alan Tyree <[email protected]> writes:
> On Wed, Oct 28, 2009 at 12:51 PM, Daniel Pittman <[email protected]>wrote:
[...]
>> It is there; the two common problems are that low memory fills, causing
>> extra competition, and that your memory bandwidth is terribly reduced
>> through extra TLB flushing to bounce data up above the easy line.
>>
>> You probably don't notice any performance hit because, frankly, almost
>> every computer you can buy — including the one in your mobile phone — is
>> sufficiently overpowered for the work it is asked to do[1] that you can
>> sacrifice ten or twenty percent of performance[2] without noticing.
>
> That's interesting, Daniel. So what are my tradeoffs. Run the normal kernel:
> faster but only 2.5gb; Run the bigmem kernel and suffer the performance but
> have more memory.
Pretty much. Alternately, use a 64-bit kernel, and this all goes away.
(Use a 64-bit kernel and 32-bit userspace and it *still* goes away; according
to some of the LKML developers this is their current approach and is pretty
much trouble free — but that may have a "...if you are a kernel developer"
caveat attached to the "pretty much" part. ;)
> Aside from the work mentioned above, I also edit some really big video files
> and do ffmpeg transformations on them. So, is there some way of choosing
> which of the above is the best option for me?
Yep: benchmark what you actually do. ;)
Otherwise, no, there isn't any easy way to do it. Well, except that it is
probably sensible to avoid the cost if you only have 1GB of RAM, total, in the
machine.
For an extra 1.5GB you /probably/ save enough just having it as disk cache
that you have an overall win.
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
Looking for work? Love Perl? In Melbourne, Australia? We are hiring.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
