Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
PS: Those two projects has a redhat employed maintainer ;)
Looking at Fedora 14 and Ubuntu 10.10
Posted Sep 7, 2010 21:37 UTC (Tue) by DOT (subscriber, #58786)
Posted Sep 7, 2010 22:27 UTC (Tue) by busterb (subscriber, #560)
Here's the code for it:
Posted Sep 8, 2010 21:12 UTC (Wed) by cjwatson (subscriber, #7322)
The Ubuntu installer has always been based on the Debian installer ("d-i"), and given our heritage as a distribution it makes a lot of sense to take that route. While the version you see on Ubuntu desktop CDs has a customised frontend, much of the backend code is shared with d-i, and this is particularly so for the partitioner - partitioning code is sufficiently delicate that we have no desire to maintain two entirely separate versions of it!
d-i's partitioner is called partman, and it's been used in all versions of Debian since 2004 or so, and in all versions of Ubuntu. We have contributed extensively to d-i over the years, and I'm one of the primary developers of partman among other things. (I guess it isn't fashionable to regard Debian as an upstream or something, but in this case it certainly is.) Like many partitioners, partman uses libparted, one of whose maintainers indeed works for Red Hat.
If you select "Specify partitions manually (advanced)" in the current Ubuntu graphical partitioner, you'll get something that's essentially a graphical rendering of partman's dialogs (though there are a couple of features missing). I wrote that graphical frontend for Ubuntu, and it has not been changed much in 10.10. The big changes are in the automatic partitioner, whose job it is to supply a small number of clear common-case options; Michael Forrest gave us a new design for that, and Evan Dandrea implemented it. Those changes, the ones mentioned in the main article, can and should be credited to Ubuntu.
Posted Sep 8, 2010 21:58 UTC (Wed) by jspaleta (subscriber, #50639)
Posted Sep 8, 2010 22:21 UTC (Wed) by cjwatson (subscriber, #7322)
Posted Sep 21, 2010 10:07 UTC (Tue) by Wol (guest, #4433)
On a 2Gb ram machine it gave me a default 2Gb swap. This machine dual-boots gentoo, and I *need* 10Gb usable memory (to compile OOo). Would SuSE let me increase the size of the swap partition? No it wouldn't! Even shrinking another partition to make room it refused to give me more swap :-( It seems all are capped at whatever SuSE thinks is the best default, and all you can do is free up space, not reuse it elsewhere :-(
And my default rule for swap anyway is (given that disk is cheap) is "twice max ram" which on my mobo is 32Gb. People have been saying "the twice ram rule is obsolete" since before linux was born ... then 2.4 proved they were wrong! I haven't seen anything (yes I know there's been some major rewrite since then) that says the actual underlying algorithm has changed, so I still stick to the rule. If it still holds it means there's some (minor) performance hit if you have less ram.
Posted Sep 24, 2010 12:55 UTC (Fri) by nix (subscriber, #2304)
The rule for swap is really 'configure as much as you need'. Swap partitions aren't much faster than swapfiles these days, so adding swap as needed isn't penalized anymore.
Posted Sep 25, 2010 20:24 UTC (Sat) by gvy (guest, #11981)
Did you consider multiple swap partitions, or emergency swap files (which aren't as nice as swap partitions/spindles but hey, if you need that much virtual memory actively you should go after more RAM)?
> People have been saying "the twice ram rule is obsolete" since before
> linux was born ...
I'm not to cry "prooflink!!11" but for 4, 8, 16, 32M RAM it was perfectly the rule. Somewhere near 64M RAM things became less apparent for desktop as working set more or less got into that plus 1x swap.
> then 2.4 proved they were wrong!
There were quite a few VM managers for 2.4.x, and at some time a bug has caused the "need" in 2x swap which is probably what you heard and recall when it was long fixed.
My main reasons for large swap these days are tmpfs for hasher package builds (with swap on 15kRPM SAS drives, and not heavily used -- rather "just to free up memory before having to clean up") and hiberation (where again, I have a hard time filling up RAM to get all of the RAM+VRAM+tinybit swap used by hibernation alone).
My, and probably yours either, main reason *not* to do uselessly large swaps is the time needed to write or read it all. If you're not going to wait for minutes, that is -- hdparm -t/-T will help to estimate both hard disk's and RAM read speed, and bc -l to turn that into full swap read time.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds