Recent Features
| |||||||||||||
Still waiting for swap prefetchStill waiting for swap prefetchPosted Jul 25, 2007 22:55 UTC (Wed) by mgb (guest, #3226)Parent article: Still waiting for swap prefetch
"for example standard overnight cron jobs shouldn't need swap prefetch on a 1 or 2GB system"
Now I've been programming since magnetic drums were hip so I may be a bit confused here but it seems to me that I can remember a time less than a decade ago when a system didn't need a couple of gigs to run Linux well.
It seems that Linux may still be a little more efficient than Vista on most loads (but not Firefox) but back in the nifty nineties Linux was a _lot_ more efficient than Windows. In short, Linux has been getting worse faster than Windows.
(Log in to post comments)
Still waiting for swap prefetch Posted Jul 25, 2007 23:04 UTC (Wed) by elanthis (guest, #6227) [Link] _Linux_ has been getting worse, or the shit that people use on their systems is getting worse?
I run 2GB in my home machine, but I don't think I've ever seen the memory peak over 1GB of actual usage. Over 60% of that is just file caches and the like - unnecessary but nice performance enhancements, basically.
Now, there are some things that we use these days that eat up a shit load of memory. My mail client has to track some 40,000 messages among all my folders. Firefox has to deal with Youtube videos. I have Tracker indexing my file system. I have more data in a single file than a hard-drive 15 years ago could even hold.
There is a lot of fat in the current desktop system, that is for sure. Ubuntu and Red Hat both have this obsession with Python, which is about as bloaty a language as you can get, and then they write crappy apps in Python that would be slow as molasses even in C because they use crappy algorithms.
Still waiting for swap prefetch Posted Jul 25, 2007 23:20 UTC (Wed) by xorbe (subscriber, #3165) [Link] When I have 2GB of ram in my home desktop system, I never ever want to see Linux drop binaries from ram, and swap them back in from the binary text file. Or see it drop data pages to increase hdd cache in memory.
Still waiting for swap prefetch Posted Jul 25, 2007 23:40 UTC (Wed) by johnkarp (subscriber, #39285) [Link] Even when the disk-cache-pages are more frequently used than theprogram-text-pages? If I understand things correctly, a program has to wait ~9ms when the data it needs is on the disk, whether its program text or data. Also, programs often have pages that are *never* used after startup; the sooner those pages are evicted in favor of useful things the better.
Still waiting for swap prefetch Posted Jul 25, 2007 23:47 UTC (Wed) by sjlyall (subscriber, #4151) [Link] When I have 2GB of ram in my home desktop system, I never ever want to see Linux drop binaries from ram, and swap them back in from the binary text file. Or see it drop data pages to increase hdd cache in memory.Turn off swap then if you feel that way. I've got no problem with my system swapping out the getty copies which will never be used and instead using the RAM to cache my mail files. I have a bunch of stuff that includes running programs, program data and files that the CPU has to deal with. I want everything to go as fast a possible so whenever possible if the CPU wants some of that data it should be able to get it as quickly as possible which means it should be in RAM if at all possible. The better the kernel does this, the faster everything will run.
Still waiting for swap prefetch Posted Aug 7, 2007 2:33 UTC (Tue) by xorbe (subscriber, #3165) [Link] Even with swap off, kernel can drop the program text, and swap it in from the backing binary on disk -- all without a swap file.
OpenOffice comes with a "pagein" utility. Posted Jul 26, 2007 0:14 UTC (Thu) by dmarti (subscriber, #11625) [Link] Why should the kernel have to guess what to page back in when you could use the "pagein" from OpenOffice, or something like it? Here's a simple example.
OpenOffice comes with a "pagein" utility. Posted Jul 26, 2007 0:39 UTC (Thu) by corbet (editor, #1) [Link] Interesting. It's doing something different, though: it's indiscriminately bringing in pages from the program's text area. I can't see how it could do anything about process anonymous pages which have been shoved into swap. Somebody who really wanted to enjoy their coffee hot would want to use both pagein (for text) and prefetch (for data) - and find some, currently unknown way to balance the two.
IWFM Posted Jul 26, 2007 16:13 UTC (Thu) by dmarti (subscriber, #11625) [Link] Subjectively, for me, running that shell function seems to get rid of the lag on alt-tab to Firefox, Gimp, or OpenOffice first thing in the morning.
What would be better, for a desktop system, would be a "goodnight" script that would run housekeeping tasks such as updatedb and logrotate, then page back in whatever the user had been working on, then suspend.
explicit pagein Posted Jul 27, 2007 22:12 UTC (Fri) by giraffedata (subscriber, #1954) [Link] To avoid the manual step (either good morning or good night), I run this in a cron job every hour all day. It doesn't matter that the interactive programs get paged in uselessly several times during the night; even if done right in the middle of updatedb, they just get paged right out again and the cost is insignificant.I also send messages through some response-time-critical daemons regularly, to "loosen them up." I.e. page in executables, anonymous pages, etc.
Still waiting for swap prefetch Posted Jul 27, 2007 0:05 UTC (Fri) by jschrod (subscriber, #1646) [Link] Then you will be surprised.
When you get 2GB (I have them), just start Eclipse on a larger project, while Firefox and Thunderbird are running; and watch your memory getting used. And you didn't even start any VM (Xen or VMware)...
Still waiting for swap prefetch Posted Jul 25, 2007 23:50 UTC (Wed) by kune (guest, #172) [Link] If Firefox is really faster on Windows than on Linux, then it should be easy to hack some benchmarks in Javascript to prove it. Nobody will be able to fix it, if he cannot measure the performance. And Internet network bandwidth has be taken out of the equation.
Sure, you can write bad code in any language, but in my experience Python is not particularly slower than other script languages. Here is a benchmark that appears to validate that experience: http://www.timestretch.com/FractalBenchmark.html Another one is here: http://acker3.ath.cx/wordpress/archives/7
Lua might be something to look at.
Of course you will always be able to write faster code in C, but this will take you some more time.
Still waiting for swap prefetch Posted Jul 25, 2007 23:53 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] Besides, for a GUI program "written in Python" all the expensive code is actually in libraries that are written in C or C++, with a thin binding to allow calls from Python. yum isn't slow because of Python, but because it does way too many system calls and I/O.
Still waiting for swap prefetch Posted Jul 26, 2007 0:09 UTC (Thu) by briangmaddox (subscriber, #39279) [Link] "Of course you will always be able to write faster code in C, but this will take you some more time."
Ya had me until you said this. Why stop at C, when it could be written in ASM? And heck, how do you know the assembler will generate fast code, better do it in hex instead.
I would have thought that after all these years that people would learn more about computer science and programming than to troll the "C is always faster than everything else" line.
Still waiting for swap prefetch Posted Jul 26, 2007 5:15 UTC (Thu) by wilreichert (subscriber, #17680) [Link] "Ya had me until you said this. Why stop at C, when it could be written in ASM? And heck, how do you know the assembler will generate fast code, better do it in hex instead."
Hex? No thanks, i prefer to hack the macro assembler and control the logic gates on my cpu directly.
Still waiting for swap prefetch Posted Jul 26, 2007 9:46 UTC (Thu) by nix (subscriber, #2304) [Link] The thing to do is to generate the assembler and then munge it with a horrible perl script.
(Hey, ghc does it, it must be good! :) )
Still waiting for swap prefetch Posted Jul 26, 2007 12:04 UTC (Thu) by dcoutts (guest, #5387) [Link] Shh! You're not supposed to tell people about that, it's called the Evil Mangler for a good reason.
Still waiting for swap prefetch Posted Jul 26, 2007 13:51 UTC (Thu) by nix (subscriber, #2304) [Link] Having just watched it use fifteen minutes of CPU time (on the ghc lexer, natch) I think it needs bringing into the light so it can be optimized by some hardier soul than I :)
program speed vs programming language Posted Jul 27, 2007 23:06 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Why stop at C, when it could be written in ASM? That's not a natural progression. Code compiled from C is often faster than that compiled from assembly language, for the same reason that a computer can land an airplane more smoothly than a human. Even code compiled from C by a naive compiler (e.g. gcc -O0) is unlikely to be slower than code compiled from assembly language. C is that low-level a language. how do you know the assembler will generate fast code, better do it in hex instead We do know that. The assembler will generate code that is not only the same speed as that generated by the hex editor, but is actually the same code. That's the definition of assembly language. I would have thought that after all these years that people would learn more about computer science and programming than to troll the "C is always faster than everything else" line. The only line I saw was, "C is always faster than Python." And it is, isn't it?
program speed vs programming language Posted Jul 31, 2007 12:08 UTC (Tue) by liljencrantz (guest, #28458) [Link] Depends on how you define your scope. I've seen situations where people solve the same problem in different languages, and because they have to spend so much time to do _anything_ in a low-level language, they are forced to chose a dumb algorithm, whereas people coding in a high level language can spend more time on the high level logic and can therefore chose a fast algorithm.
Still waiting for swap prefetch Posted Jul 26, 2007 9:44 UTC (Thu) by nix (subscriber, #2304) [Link] Benchmarks in Javascript will mostly show the performance of the JS interpreter and things it can block on, i.e. it's not a complete monitoring tool by any means.
Still waiting for swap prefetch Posted Jul 26, 2007 7:46 UTC (Thu) by pointwood (guest, #2814) [Link] "Ubuntu and Red Hat both have this obsession with Python, which is about as bloaty a language as you can get, and then they write crappy apps in Python that would be slow as molasses even in C because they use crappy algorithms."
Could you elaborate on that? I'm not much of a coder, but it would be interesting to hear what the problem with python is since I have considered playing with it.
In regards to Ubuntu and Redhat, well I bet they are open for improvements to their code though you don't say what apps it is. Your comment lacks facts.
Still waiting for swap prefetch Posted Jul 26, 2007 8:28 UTC (Thu) by rsidd (subscriber, #2582) [Link] There's nothing wrong with python (or other high-level languages), and it worked fine on linux systems 10 years ago. C is faster only for CPU-bound tasks, which hardly any system tasks are. C may be less memory intensive (it depends on what libraries you're using, what your coding style is, and so on), but with C you have to be careful about all kinds of bugs and security holes (buffer overflows, memory leaks, etc) that even experts get bitten by, but don't occur with high-level languages.
Still waiting for swap prefetch Posted Jul 26, 2007 12:23 UTC (Thu) by rwmj (subscriber, #5474) [Link] Oh dear no there's _plenty_ wrong with Python. It's dynamictyping nature means that simple objects have huge amounts of baggage that they have to carry around, mostly never used.
C sucks for programming too, for the reasons you outline.
But guess what folks! C and Python are not the only programming
My personal fave at the moment is OCaml. About as fast as C,
Rich.
Still waiting for swap prefetch Posted Jul 27, 2007 11:56 UTC (Fri) by IkeTo (subscriber, #2122) [Link] > C and Python are not the only programming> languages in the world!! You won't believe it, but other > programming languages have been invented.
> My personal fave at the moment is OCaml. About as fast as C,
Two suggestions. Suggestion 1: start lobbying people all around to start using OCaml: universities, companies, etc. If you are successful you have a bunch of people who *know* what it is (currently the people with that characteristics are so few that it doesn't matter). Or choose suggestion 2: start implementing some *real cool* thing in OCaml, making sure that developing the equivalent thing (e.g., with same performance, flexibility, etc) is so expensive that nobody can do *because of a choice of different language*. Then you serve as an example showing others the real benefit of the language.
Before you do so, accept that languages behaving the same way as in C or Python are those who know by those who work on creating applications. Problem is, money talks. If the industry do need C and Python, that's what's university courses teach, that's what's people know, and that's what applications will be written in.
Still waiting for swap prefetch Posted Aug 2, 2007 7:40 UTC (Thu) by renox (subscriber, #23785) [Link] My problem with Ocaml is its syntax and its functional mindset: I tried once to learn Ocaml and I disliked the syntax plus the PDF book I used insisted on using functional way to solve everything which is strange as Ocaml is said to support both imperative and functional style, why the book insisted so much on the functional style is beyond me, bleach.
So to be successful, Ocaml would need 2 things:
Somehow I doubt that will happen, so Ocaml is bound to stay in the limelight..
Still waiting for swap prefetch Posted Jul 26, 2007 15:15 UTC (Thu) by arjan (subscriber, #36785) [Link] > There's nothing wrong with python
... except that even a simple "hello world" seems to take 40 megabytes of memory. It's not about a few cpu cycles that kills you in performance, it's the enormous overhead that even simple programs get....
Still waiting for swap prefetch Posted Jul 26, 2007 17:11 UTC (Thu) by vmole (guest, #111) [Link] That is so much crap.$ cat hello.py import time print "hello, world" time.sleep(30) % python hello.py & [1] 25243 hello, world $ ps l -C python F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND 0 1000 25446 2688 17 0 3844 2256 - S pts/0 0:00 python hello.py So that's 2M resident, 4M virtual. And it exagerates a simple "hello world" program, because I had to import the time module for sleep() so I could run ps. Most of it is the interpeter itself, so multiple python programs don't actually take 4M each. Python isn't perfect - what language is? But don't make stuff up, it just ruins your argument.
Still waiting for swap prefetch Posted Jul 26, 2007 19:01 UTC (Thu) by nevyn (subscriber, #33129) [Link] Let's try longer than 30 secs, eh? % ps ax -o cmd:50,vsz,rss,stime | egrep '[p]ython' /usr/bin/python -E /usr/sbin/setroubleshootd 808024 12104 Jul06 python /usr/share/system-config-printer/applet.py 232764 6436 Jul06 /usr/bin/python -E /usr/bin/sealert -s 411728 18524 Jul06 python /usr/libexec/revelation-applet --oaf-activa 458328 55056 Jul06 python /usr/lib64/gdesklets/gdesklets-daemon 453980 65768 Jul23 python ./hpssd.py 171220 1176 Jul11 ...that's 2_536_044 KB VSZ and 159_064 KB RSS, and as you can see I've rebooted gdesklets recently (it was roughly double that, I think). Plus I'm not running pupplet/yum-updatesd atm. And for instance "revelation-applet" is just a text entry box 95% of the time. I appreciate that the huge VSZ numbers are (hopefully) mostly unused shared libs. etc. but half a GB is still a lot for the OS to manage for a text box, and 40+MB of RSS for a simple GUI is far from "so much crap". For comparison my webserver uses two processes with a VSZ of about 12MB each and RSS of about 1MB each, and I'd prefer that to be smaller.
Still waiting for swap prefetch Posted Jul 26, 2007 19:24 UTC (Thu) by vmole (guest, #111) [Link] You said "a simple hello world" program, and that's what I tested. Comparing GUI programs to a webserver is irrelevant. What you've mostly demonstrated is that that GNOME/GTK is huge. Blaming that on Python doesn't seem to make sense. I'd bet a Perl implemenation of the same programs would be equally huge.
Still waiting for swap prefetch Posted Jul 26, 2007 9:37 UTC (Thu) by nix (subscriber, #2304) [Link] The page cache is not an `unnecessary but nice performance enhancement'. The text pages of all your binaries are sitting in there while they run, as is all your other mmap()ed stuff. If your page cache was empty you'd not be able to run any userspace code to speak of.
Still waiting for swap prefetch Posted Jul 26, 2007 13:22 UTC (Thu) by cate (subscriber, #1359) [Link] _Linux_ has been getting worse, or the shit that people use on their systems is getting worse?Check the size of a Linux kernel, and you will see that the is a bigger increment (in percent) in 5 years than the memory used by mozilla. We have more memory, so we can afford to use it more inefficiently.
Still waiting for swap prefetch Posted Jul 26, 2007 16:19 UTC (Thu) by khim (subscriber, #9252) [Link] I was barely able to boot Linux on 2MB system back then. Today I need 8Mb for that. Netscape was quite useful on 12MB Linux system (8MB was too slow), today you can barely even start Firefox on 48MB system. Huge size of Linux kernel in real life is mostly page tables so I think Linux and Firefox grew in unison...
Still waiting for swap prefetch Posted Jul 30, 2007 8:35 UTC (Mon) by gouyou (subscriber, #30290) [Link] We have more memoryNot really take a look at the OLPC or at the new development on the embeded device scene (Nokia N770/N800, OpenMoko) ...
Still waiting for swap prefetch Posted Aug 3, 2007 4:04 UTC (Fri) by bersl2 (subscriber, #34928) [Link] "We have more memory, so we can afford to use it more inefficiently."That's badly worded. It would be more correct to say that memory efficiency has been sacrificed for time efficiency.
Still waiting for swap prefetch Posted Jul 25, 2007 23:56 UTC (Wed) by ronaldcole (guest, #1462) [Link] Let's clarify... in a GNU/Linux system, the GNU part is getting bigger and slower. I can still happily load and run Debian 4.0 on a DX4/100 with 32M of ram and a 2G hdd. Can't do anything that involves a GUI, though.
Still waiting for swap prefetch Posted Jul 26, 2007 0:03 UTC (Thu) by tomsi (subscriber, #2306) [Link] It seems that Linux may still be a little more efficient than Vista on most loads (but not Firefox) but back in the nifty nineties Linux was a _lot_ more efficient than Windows. In short, Linux has been getting worse faster than Windows. I am not sure if I agree with that. I am writing this on a Dell laptop with a 1GHz CPU and 512MB of memory. It is a pain to use on Windows XP, and I wouldn't dare try to put Vista on it. But latest version of Ubuntu trundles along quite nicely. There are a few applications that struggles; like eclipse; but they struggled 3 years ago too. Tom
Bloat Posted Jul 27, 2007 0:16 UTC (Fri) by jmorris42 (subscriber, #2203) [Link] > I am writing this on a Dell laptop with a 1GHz CPU and 512MB of memory.
You say that like you think that is a small machine. It shouldn't be, and that is the problem.
I remember running early GNOME based RedHat distributions on 300Mhz machines with 128M and it being totally usable. Bumped it to 256MB and could run Win95 under VMWare. (Gave Windows 64MB)
Now look at the pitiful state of bloat we have. Anaconda pretty much requires 512MB now unless you install in text mode. Red Hat won't even support a RHEL machine without a full GB. And I know ps's memory stats aren't all that reliable but look at the memory and CPU needs to bring up a GNOME or KDE desktop and a browser.
And speaking of insane, take a look at conglomerate. I have a test machine loaded up with F7 (Athlon64 2800 with 512MB) and tried using conglomerate to open up the Fedora 7 comps.xml file. After several minutes of constant thrashing went by as the poor machine exhausted all memory and swap the OOM killer finally put it out of it's misery. This is a 0.9 release so I'm assuming this sort of memory performace isn't considered a show stopper bug. More likely none of the devels (who by definition have big enough machines to compile a hog like Conglomerate) noticed the memory consumption.
I think the problem probably stems from the same source as Window's bloat. The developers no longer feel the pain. Ten years ago many key developers on every part of the stack from kernel to desktop (browser excluded prior to Mozilla becoming viable...) were private individuals, with a fair number outside the US/western Europe. The upshot of that was that they had hardware closer to a 'typical' machine. Now most of the key developers are using machines bought with OPM, i.e. corporate developer 'workstations' with big honking specs.
Perhaps the key developers should be given a $1,500 budget to buy their workstation with and then give them assess via ssh to a 'compile host' so they don't have to sit and spin waiting for compiles but DO have to sit and spin waiting on OO.o or Firefox. This would motivate them to care about resource consumption in more realistic desktop environments and not just care how well their quad Opteron monster squeezes the last percentage from all of it's CPUs.
Bloat Posted Jul 29, 2007 21:35 UTC (Sun) by njs (guest, #40338) [Link] >Perhaps the key developers should be given a $1,500 budget to buy their workstation with
Err... you can get 2GB of memory for < $100 these days. From a glance at dell.com, right now $550 low-end desktops come with 1GB of memory default, and $750 ones with 2GB. There are still real cases where memory is limited (embedded devices, OLPC, people living in non first-world countries, ...), but your scale seems a bit miscalibrated.
Bloat Posted Aug 6, 2007 20:49 UTC (Mon) by happycube (guest, #42855) [Link] The real problem is with older hardware - it's impossible to get more than 512MB in an i815-based P3, for instance.
Bloat Posted Aug 9, 2007 2:28 UTC (Thu) by jmorris42 (subscriber, #2203) [Link] I really hate this notion that a three year old computer should be tossed in the trash as so obsolete there is no use it can be put to. Linux used to be a good way to get good use out of older hardware. Not anymore. Now you need hardware equal to, and prior to Vista shipping greater than, the minimum Windows baseline.
And just throwing hardware at the problem doesn't make it go away. Having 2GB of RAM will make it livable but hard drives aren't getting all that much faster. Paging in enough of OO.o and all the libraries it needs to get to mapping the initial window means looking at a throbber almost as long on a hot new monster PC as it does on an older one. Same for all the disc thrashing involved in logon as multi-megabyte blobs of libraries and executables are mapped in to provide what should be small crap like battery indicators and CPU speed monitor widgets in menu bar.
Having more resources is no excuse for sloppy and wasteful practices. And if we want our stuff to be an option for the coming world of smart phones, flash based laptops (without swap) and the embedded world we need to be thinking about getting our act together now.
non-sequitur Posted Jul 26, 2007 1:14 UTC (Thu) by qu1j0t3 (guest, #25786) [Link] Memory 'needs' increase exponentially in a Moore's Law like process that is entirely unrelated to Linux. You can still run Linux on tiny systems (I know people running 2.6 on systems smaller than 32MB), which is not true of any recent version of Windows.
Your conclusion simply does not follow from Nick Piggin's quite reasonable postulate.
Still waiting for swap prefetch Posted Jul 26, 2007 1:56 UTC (Thu) by sobdk (guest, #38278) [Link] Now I've been programming since magnetic drums were hip so I may be a bit confused here but it seems to me that I can remember a time less than a decade ago when a system didn't need a couple of gigs to run Linux well. I would say it still does. I'm writing this as we speak from a PIII 700 MHz with 256 MB of RAM and honest Linux runs great. I even use Firefox which tends to eat up 50% of my RAM according to top, but still no complaints. In fact even with Firefox using half my RAM I'm still not even touching swap. Interestingly enough when I read some of the posts on lkml claiming that they had 1GB of RAM and swap prefetch drastically improved their workload, all I could think is "what on earth are these people running?" Until a couple of months ago my dev-machine at work only had 512 MB of RAM and had all kinds of nasty things like Firefox, beagle, and Lotus Notes running but my swap was rarely used. Conversely on days when I was forced to boot it into Windows XP for one reason or another I couldn't leave an application minimized for more than 10 minutes before Windows decided to swap it out. Waiting 1 minute every time I switch apps on Windows is enough to make me go crazy and be thankful that Linux has a sane swapping algorithm.
Still waiting for swap prefetch Posted Jul 26, 2007 2:41 UTC (Thu) by Richard_J_Neill (subscriber, #23093) [Link] Hmm - I've just upgraded to a 64-bit desktop machine. The principal reason is so that firefox can address > 4GB of swap (!). Really, FF crashes on me about once a week, because although I have 2GB RAM and 6GB of swap, firefox manages to malloc() 4 GB! No idea where it is going - admittedly I tend to have about 200 tabs open, but that alone shouldn't be the problem.
Still waiting for swap prefetch Posted Jul 26, 2007 14:51 UTC (Thu) by lysse (guest, #3190) [Link] Well, 200 tabs at about 2Mb per tab would use up your 4Gb quite effectively...
Off by an order of magnitude? Posted Jul 26, 2007 20:29 UTC (Thu) by martinfick (subscriber, #4455) [Link] 200 * 2MB = 400MB != 4GB
Off by an order of magnitude? Posted Jul 27, 2007 6:04 UTC (Fri) by man_ls (subscriber, #15091) [Link] Let's make it 20 MB then per tab. If each page is three screens high, and my screen is 1680x1050, with 4 bytes per pixel (3 colors + alpha):1680 x 1050 (pixels/screen) x 4 (bytes/pixel) x 3 (screens) = 20672 MB. We do want the pages to be cached when we switch tabs, don't we?
Off by three orders of magnitude! Posted Jul 27, 2007 6:06 UTC (Fri) by man_ls (subscriber, #15091) [Link] That should read 20672 KB, sorry.
Off by an order of magnitude? Posted Jul 27, 2007 14:36 UTC (Fri) by Los__D (guest, #15263) [Link] Yeah we do, but does it really cache a bitmap of the page? That would seem a bit silly
Bitmap cache Posted Jul 27, 2007 21:57 UTC (Fri) by man_ls (subscriber, #15091) [Link] Yeah we do, but does it really cache a bitmap of the page?I don't know exactly, but I would say it does. Loading a couple of big JPEG files takes quite longer than changing tabs between them. That would seem a bit sillyWhy, exactly? If you have the RAM to spare, it seems to be as good as any other use. I seem to remember some discussion on LWN about Firefox caching even pages in the history. When people complain that "Firefox eats up 2 GB" in a 4 GB machine, it gives the wrong impression. Firefox runs fine on my 128 MB laptop, and memory seldom goes above 80 MB.
Bitmap cache Posted Jul 28, 2007 13:38 UTC (Sat) by Los__D (guest, #15263) [Link] I would never (never EVER) suggest using JPEG for computer graphics, but caching in PNG would seem smarter than a bitmap, and not really that much slower. Of course, when you only have 3-4 tabs, it wouldn't really matter, but as the count goes up, you can much better afford the CPU than the memory. Plus, the CPU is only when you change, the memory usage is constant.
I'm not completely sure how uncompressed PNG would handle the JPEG's on the page, but I couldn't imagine it getting worse (memory wise) than bitmap, just equal. (I've been known to be naive in my expectations from formats though).
The browser (toolkit?) could of course also do some kind of checking of available memory, and change algorithm from that, but maybe that is an unneeded complexity.
I don't know, maybe it's easiest/simplest and mostly correct to just keep the rendered pages as is in memory, but for some usage patterns, it does become a huge waste of memory.
Bitmap cache Posted Jul 28, 2007 13:51 UTC (Sat) by man_ls (subscriber, #15091) [Link] I would never (never EVER) suggest using JPEG for computer graphicsI wouldn't either. My little experiment with JPEG images involved decompressing a JPEG image vs. caching an uncompressed bitmap. Caching images in a lossy format would be ludicrous. But caching in a lossless format such as PNG isn't such a good idea either. An important aspect of caches is that you should store an artifact which you already have, not one you have to generate. If you have to compress a bitmap to PNG before caching it, you are wasting a lot of CPU time just to generate a cache which you might as well never use again. An example: you download a JPEG image, then uncompress it to show it, and then you compress it to PNG before caching it in memory. Messy.
Bitmap cache Posted Jul 28, 2007 14:00 UTC (Sat) by Los__D (guest, #15263) [Link] It really depends on the cost of CPU vs. the cost of memory.
For most usage patterns, I agree, but for those that likes to have 30+ tabs open (for some reason), caching the uncompressed bitmap is a _big_ waste.
The question is if the best approach wouldn't be to just forget or limit those caches for that kind of usage. At least the bitmap approach is asking for disk trashing.
Bitmap cache Posted Oct 9, 2007 18:49 UTC (Tue) by Blaisorblade (guest, #25465) [Link] I've read time ago a comment from a OLPC developer on exactly this issue. I'm writing a summary of his comments I recall.Basically, an application can store an uncompressed bitmap in the X server. And Firefox caches all images this way! That's the problem. Probably avoiding the caching would be even faster (due to no swapping).
IMHO (and this is my opinion, I don't recall his one) a reasonable solution would be to extend the X protocol to allow caching compressed images in most reasonable formats (including especially JPEG). Then the X server can keep a cache of most shown decoded images.
Since the JPEG compression ratio is huge, there would be a huge gain from this.
Off by an order of magnitude? Posted Aug 9, 2007 1:51 UTC (Thu) by lysse (guest, #3190) [Link] Quite right. Sorry. Oops.
Still waiting for swap prefetch Posted Jul 28, 2007 3:43 UTC (Sat) by roelofs (guest, #2599) [Link] Really, FF crashes on me about once a week, because although I have 2GB RAM and 6GB of swap, firefox manages to malloc() 4 GB!Geez, what are you doing to the poor thing?? No idea where it is going - admittedly I tend to have about 200 tabs open, but that alone shouldn't be the problem. OK, that might do it... I have two FF windows containing a total of 9 tabs, and it's been running since early March. Total memory usage (per ps(1)): 197M allocated, 157M resident. (Of course, there's also X11 pixmaps, as was noted in another LWN article a while back. I've forgotten how to check that, but even if FF were the sole X client--which it's not, by far--that's only another 194M allocated and 46M resident.) Greg
Still waiting for swap prefetch Posted Aug 1, 2007 2:23 UTC (Wed) by set (guest, #4788) [Link] xrestop will show you the X memory usage, such as pixmaps.
Still waiting for swap prefetch Posted Aug 1, 2007 16:43 UTC (Wed) by zlynx (subscriber, #2285) [Link] One of these days someone needs to add the amount of CPU X spent per client to xrestop.
Still waiting for swap prefetch Posted Aug 3, 2007 23:45 UTC (Fri) by roelofs (guest, #2599) [Link] xrestop will show you the X memory usage, such as pixmaps.Danke, sir! That's the command I couldn't recall. Greg
Still waiting for swap prefetch Posted Jul 26, 2007 2:14 UTC (Thu) by h2 (guest, #27965) [Link] >I can remember a time less than a decade ago when a system didn't need a couple of gigs to run Linux well.
Don't worry, it's still fine, running 2.6.22.1 kernel on old hardware, with a light desktop, xfce4, running lots of little server things, nfs, vnc, streaming, etc, the system using... 90 mB ram, out of 192 mB total. I originally had 512 in it but it never got remotely close to using it so I pulled it out and put back in small sticks I had lying around. Once in a while it uses swap, a tiny bit, but not often.
For full desktop like kde or gnome, 256 is what you need to avoid swapping.
And more for dev work, vmware, heavy graphics, and so on. Just because you put in 2 gig doesn't mean you use it, this box has 2 and it's using 3/4 gig with 50 or so apps open on 8 virtual desktops. But fire up a vmware or vbox install or two and you're getting closer to 2 gigs.
|
|||||||||||||