| Linux development on the PlayStation 3, Part 2: Working with memory | ||||||||||||||||||||||
| 摘自: IBM developerWorks Worldwide 被阅读次数: 56 | ||||||||||||||||||||||
由 yangyi 于 2008-06-22 14:44:24 提供 | ||||||||||||||||||||||
Level: Intermediate Peter Seebach (developerworks@seebs.plethora.net), Freelance author, Plethora.net 31 Mar 2008 The Sony PlayStation 3 (PS3) runs Linux®, but getting it to run well requires some tweaking. In this article, the second in a series, Peter Seebach takes a look at where all the memory goes and how to reclaim it. In Part 1 of this series, I introduced PlayStation 3 (PS3) Linux and its strengths and weaknesses as a development environment. This second part covers some of the things that can have a significant impact on a PS3 system's performance running Linux. Not every piece of advice here will work for everyone. If you're doing graphics, you can't just run the system without X. On the other hand, if you're not doing graphics, nothing else makes as much of a difference in the system's memory footprint. The focus on memory may seem odd if you're used to desktop systems that have never mounted a swap drive in anger, but, in fact, the PS3 doesn't have enough memory for a modern desktop Linux to feel comfortable on it out of the box. With a default Fedora 7 install, the system spends a lot of its time (and yours) swapping. Swapping imposes a large penalty on any system; on a system built around a 2.5-inch disk drive accessed through a hypervisor, with main memory that's substantially faster than what you find in most desktops, the contrast is even sharper than it is on a more traditional desktop system. One other note: On my test system, rebooting was unreliable under the 2.6.21 kernel that was originally installed. The 2.6.23 kernel fixed this, using either the version from the PS3 addons CD, or the version from the standard Fedora updater. In general, the kernel from the PS3 addons CD is probably your best bet. This topic comes and goes in importance. For most desktop Linux users, the idea that you'd need to actually do something to reduce memory usage is a distant memory. Furthermore, because processes tend to grow to fill available space, even when a machine with 64MB of main memory was considered a powerful server, there simply wasn't as much software running, and it didn't need as much memory. The PS3 is one of the systems where memory usage matters a lot, though, and Fedora 7, charming though it is, has not been designed around small-memory systems. To reduce memory usage, start by identifying the largest consumers of memory.
One easy way to do this is with Listing 1. Am I really using that much memory?
Bring up You should now see a list of processes, sorted by actual physical memory usage. Here's a partial listing, again from a test machine: Listing 2. I guess I am using that much memory
The top ten or so consumers of memory are all X-related. This is why, if you really want to free up memory, one of your first choices might be to shut down X. Noticing how many of those applications are GNOME-specific, you might be tempted to try KDE, but I'm afraid that won't get you anywhere. KDE has a comparable memory footprint on the PS3. In fact, if you absolutely need X, your best option is not to use the X session
environments offered by the X login window; instead, log in on the console and
start X with a smaller window manager and fewer additional programs. But how to do
that? Your first step will be to exit
Runlevels are a feature that many Linux users never have cause to learn about.
They're essentially inherited from System V UNIX®, although there are
some differences, of course. A runlevel is a defined set of system services
that are run
together. For historical reasons, the usual desktop Linux environment, with a
graphical login program that spawns Gnome or KDE, is called runlevel 5. A
conventional standalone workstation without X would often run in runlevel 2. In
theory, you can do pretty well by just changing the system's runlevel directly
with the The default runlevel is set by a line in the /etc/inittab file, which looks like this: Listing 3. A default runlevel
The format of the line is historical, and all you really need to know to change it effectively is that you can change the 5 to a 2 or a 3. Then the next time the system boots, it will come up to a text console login prompt rather than starting X. The simple fact is, the text console is a much better choice for a development
system with limited memory than the full-bore X environment. This is a good time
to do some poking around to see what we can get rid of. Change the
While it's certainly good to have a hundred megabytes free, the system could
perhaps be slimmed down a bit more.
Another run through Listing 4. Excuse me, I don't think I ordered that
By far, the largest program is yum-updatesd, presumably a daemon related to the system's yum updater. (In the dot com era, that kind of deep insight could have gotten you relocated anywhere in the country you wanted to go.) Luckily, this is also a program we can easily do without; you can run yum by hand when you feel like it. Sadly, there's not a specific runlevel for "runlevel 3, only without yum-updatesd". That means it's time to start manually removing services. There are a couple of ways to do this. Each runlevel is defined by a corresponding directory in /etc/rc.d, named rcN.d; for instance, runlevel 3 is defined by the files in /etc/rc.d/rc3.d. (There are also symlinks to these directories in /etc, on a Fedora 7 system, but it's a good habit to use the full path.) Each such directory contains a number of files, with slightly cryptic names like "K74nscd" or "S88nasd." The naming convention is simple: names starting with a K are services to be stopped when entering this runlevel (presumably from a higher-numbered runlevel, which might have been using them), and names starting with an S are services to be started when entering this runlevel. The two-digit numbers are used to sort services; S13rpcbind is started before S14nfslock, which is in turn started before S25netfs. Simple, and effective. In fact, these are usually not files, but symlinks to scripts stored in
/etc/rc.d/init.d. Typically, there's a single script that can either start or stop
a given service, and then links to it are made appropriately.
When If you're feeling like just diving in, guns blazing, you can simply remove
unwanted S or K links from a runlevel directory. Similarly, you can add new links.
Another option is to use the As an example, if you wanted to remove the yum-updatesd program from runlevel 2,
you could simply remove the link /etc/rc.d/rc2.d/S97yum-updatesd. To remove it
from runlevel 2 with With Listing 5. Spying in Python
A quick On a fairly typical dedicated development system, the final total was 49,896KB used, down from an initial start of 213,692KB. Free memory went from 5,500KB to 169,296KB—a noticeable improvement in room to run the compiler in. The difference this makes will vary depending on your workload; many of the background daemons, once swapped out, will stay swapped out and leave your system nearly as responsive as it would be without them. Over a long period of time, though, even a smallish difference in compile times adds up.
As you see, if you're willing to sacrifice a number of unnecessary or unused features, you can reclaim a huge amount of system memory, leaving you with plenty of memory to run compilers and start developing code. However, many users will find the complete loss of X too high a price to pay. The next article in this series will look at what you can do to get a usable X environment for doing simple graphical work, without losing the ability to run the compiler. Learn
Get products and technologies
Discuss
Original link: http://www.ibm.com/developerwork... | ||||||||||||||||||||||
